Patrick Walsh
Originally published at

IronCore Labs Proxy Re-Encryption Library Audit by NCC Group

We believe there’s a right way to do things. With cryptography, that’s even more important than almost any other area of software, save perhaps if you’re writing the code for nuclear power plants or guided missiles where hidden bugs can be catastrophically bad.

Cryptography is unique in software because there are so many pitfalls to avoid. Just because something can go from plaintext to ciphertext and back again doesn’t mean it does so in a secure way.

IronCore is commercializing a type of cryptography that has been in academia for around 20 years but has yet to be used in the mainstream. Academics call this proxy re-encryption (PRE), but we call it Transform Cryptography. We’ve renamed it because, well, naming is hard and in this case, the original name implies something negative. Re-encryption in cryptography typically means a decrypt-then-encrypt flow. This is usually an undesirable thing to have to do and happens when you have to change keys or access. In the case of PRE, there is no decryption in the re-encryption process. Ciphertext is instead transformed from one recipient to another without decrypting it.

Just because something can go from plaintext to ciphertext and back again doesn’t mean it does so in a secure way.

Transform cryptography is also more narrow than PRE and includes a number of very desirable properties for use in practical systems (eg, multihop, unidirectional, non-interactive, non-transitive, CCA secure). These properties are required for strong security in our primary use case: group-enabled public key cryptography.

With transform crypto, data is encrypted to one or more groups. The group owner (or owners) can add and remove members at any time. Those members are group delegates who are able to decrypt data using their own elliptic curve private key after the encrypted data is transformed to them. This means that data can be encrypted at one point in time and separately, without touching the encrypted data, the group owner can change who is able to decrypt it. We call this cryptographic orthogonal access control, and you can read the full details, including how we handle per-device security, in our ACM paper.

Our protocol is largely based on prior work that has been attacked and refined over the course of years.

Here’s the thing with this algorithm: what we’re doing requires specific cryptographic primitives (elliptic curve pairings), that aren’t widely available. You couldn’t build this with OpenSSL even if you wanted to. So, we set out to build a production-caliber transform cryptography library with smart and fast implementation choices and first-class properties and proofs.

You couldn’t build this with OpenSSL even if you wanted to.

We built the recrypt library using functional programming paradigms as much as possible so that it’s easier to reason about the code and the resulting library is more testable (we have 94% unit test coverage versus under 50% for OpenSSL, for example). We also use property-based tests that effectively auto-fuzz the inputs to the library. But that isn’t enough.

So, we hired a well-respected third-party with a stellar reputation, NCC Group, to review our implementation.

We’re announcing today that our code has completed a crypto audit. We want to be extremely clear here: NCC Group’s auditors are incredibly smart, but their work was scoped and time-boxed. Also, cryptography is an incredibly complex and dynamic subject. We remember well that algorithms and implementation choices that were considered highly secure in the 1980’s are readily breakable today. This means that there could be as-yet-undiscovered flaws in our code or in the underlying security assumptions about the security of elliptic curve cryptography in general or our implementation choices in particular.

The review aimed in particular at validating the specific choice of the pairing-friendly elliptic curve in the protocol, and verifying that our Scala implementation is a secure incarnation of that protocol.

We highly value transparency and humility here, which is why we’ve published the full details of our algorithm along with the code that implements it. With the cooperation of NCC Group, we are now making public the findings of this audit, too. The report and summary of the scope of the audit can be found on the NCC Group website.

We think Phil Zimmerman’s “Pretty Good Privacy” (PGP) is the all-time winner for best-named encryption tool. It stands in contrast to the pervasive security industry bullshit about security that’s “unbreakable” and “bulletproof” and “military grade.” We hope to follow in Phil’s footsteps not with words (or our deliberate decision to avoid some of them), but with actions that reflect our core values.

We pledge to you that this isn’t a one-time deal. This will not be our last third-party review nor the sum total of our transparency, privacy, security, and reliability efforts. We have an active bug bounty program that invites meaningful reviews and responsible disclosures from the broader security community, and we are committed to leading the way to a world where strong data privacy and application security is the norm.

We can’t wait to see what you all build with these new capabilities in your toolkit.

About Patrick Walsh
I write and curate articles on cyber-security, privacy, encryption, law and the intersection of all of the above. I’m also the CEO of IronCore Labs, where we are changing how software is built to bring customers control of their data. To see more of this kind of content, follow our publication, The Salty Hash, on Medium. To learn more about IronCore Labs or get in touch, visit _

If you enjoyed this post, please click the 👏 button to help others find it! Feedback, critiques, and debate is all welcome.

More great reads