twitter logo linkedin logo facebook logo

Evolving the MIRACL Core library (4 min read)

Dr Michael Scott

MIRACL Core library code

Over the past few weeks our Chief Crypto Officer, the highly respected Dr Michael Scott, has highlighted the benefits of the MIRACL Trust® authentication. No need for passwords, no storing of credentials and friction free to use. MIRACL also offers a leading open source cryptographic library available in 7 computer languages. Today, Michael reminds us of this capability and the exceptionally high standards it operates under.

MIRACL Core is an open source cryptographic library, quite like no other. Its most remarkable stand-out property is that fully compatible versions are available in 7 different computer languages, C, C++,Java, Javascript, Go, Swift and Rust. Plus a cut-down Python version, and simple tool-driven conversions to Wasm and C#. You can find it here:

https://github.com/miracl/core

The library is focused on curve based cryptography. But it also includes standard hashing and AES encryption standards, legacy support for RSA encryption, and even a post-quantum module (although post-quantum cryptography isn’t really ready for show-time just yet).

Now when implementing cryptography there are very strong reasons for adhering to standards. In part because crypto is complicated, those who deploy cryptography to secure their products very much like to keep to established standards issued by trusted international bodies. These standards bubble up from the international cryptographic research community.

Now you can either love standards or loathe them, but you cannot ignore them. And to be honest sometimes we cryptographers get it badly wrong. Some standards find it hard to shake off their academic roots. Some offer far too many options, so there isn’t just one standard, but dozens of them to choose from. Best thing is for as many as possible to get involved, so that bad choices can be headed off. As you might suspect, it’s a slow process.

In the world of curve-based crypto there are some interesting standards cooking away slowly on a low heat. One involves the standardisation of pairing-friendly elliptic curves, required to implement protocols based on the relatively new science of pairing-based cryptography (of which our own M-Pin protocol is one example). To this end some Japanese scientists have taken a lead. Their current proposal can be found here

https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/

But for the purposes of this blog, we will focus on this emerging standard

https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/

….as it gives me a chance to indulge some simple mathematics. Now elliptic curve cryptography works with a set of points on a curve. Visualize a simple graph with x and y coordinates. A point (x,y) satisfies an equation that looks like

y2=x3+ax+b

For us x and y will always be whole numbers. Now for a particular protocol there may be a need to map something like an email address to a point on the curve. Seems easy, but there is a catch. Convert the email address to a whole number, and call it x. Now solve for y and we have a point (x,y). Finding y requires us to evaluate the right-hand-side of the curve equation, and then find its’square root. Now what is the square root of 4? Its 2 says you, but then you remember your school days and correct yourself. It’s actually +2 or -2. There are two square roots. And with the type of maths we use in cryptography it turns out that the right-hand-side for a randomly chosen x may have two square roots, or it may not have any square roots at all! The first case we can handle, but if no square roots exist we are in a bit of trouble.

One idea would be to keep adding 1 to x until we do get a square root. And this would be perfectly fine mathematically. Except cryptographers would recoil in horror at the very idea. Because the number of additions required would depend on x, and this information might leak out, via what we call a side-channel attack.

So how can we map an email address to a point on the curve in *constant time,*that is in such a way that the computation time is identical in all cases, for all values of x? Amazingly and counter-intuitively, due to the work of some very clever mathematicians, it can be done. And that is the whole point of this standard!

So we have been tracking these emerging standards in our MIRACL Core library, providing some input and feedback, shamelessly trying to nudge them in directions that suit our needs, while exhibiting respect and understanding towards those who have volunteered for the thankless job of shepherding us all towards a consensus.

If you would like to talk to us about our library, contact us via miracl.com or find out more here -https://github.com/miracl/core

Dr Michael Scott will be publishing a detailed paper on this topic, due for release this summer. Find out more about MIRACL’s highly secure online authentication by visiting MIRACL or stay in touch via social media, when more details will follow: Twitter@MIRACL | LinkedIn MIRACL

Get the MIRACL memo in your inbox

Get in touch to learn more

You can opt out at any time. See our privacy policy here.