Feature/signing #1358
Feature/signing #1358
Conversation
|
Is this not something mbed is capable of? Because this will mean two different crypto implementations in the library. |
|
mbedCrypto has been promising to add Ed25519 for at least three years. I found a couple issues about it in their repo, and at least twice someone has submitted a PR. It looks like they're partway through, but they promised it in a release last year and haven't delivered yet. (And that would be in a 3.x release, while we're still on 2.x.) The actual implementation of the algorithms is a small amount of code; the complexity seems to come from integrating them into all the other stuff in mbed. I've been using Monocypher for a while and it's a nice solid library. Small (2000 LOC, and Ed25519 only uses a fraction of that) and it's gone through security audit. I don't think there's actually any overlap between the crypto algorithms provided by mbedCrypto and Monocypher. (Hm, except for SHA512, which Monocypher only includes because the Ed25519 algorithm requires it.) |
|
In that case, we should set it up as an official couchbasedeps fork and put it onto a release tag so that the check submodules script will verify it correctly. |
It would be easy to add SHA384 and/or SHA512 too. Or other digest types if we add crypto code implementing them.
- Abstract API for keys that create and verify signatures. (I couldn't just use PublicKey and PrivateKey because they are tightly tied to mbedTLS and RSA.) - Implementation of it using PublicKey / PrivateKey. - Implementation of it using Ed25519 keys. - Added Monocypher submodule: a tiny crypto library that implements Ed25519. - API for signed Fleece values, using the signed-dict data format that I came up with years ago. - Unit test.
Backs out the changes made to PublicKey.
Implemented support for signing documents, actually Fleece Dicts, actually any Values. The signature is a Dict that could be stored in the document or elsewhere. This is based on my old Signed Documents spec, but modified slightly; I've included an updated spec.
Signing can use the existing PublicKey/PrivateKey classes; unfortunately these are RSA and generate really big signatures, like 256 bytes binary or 341 bytes base64-encoded.
I brought in the Monocypher crypto library to get support for Ed25519 keys, which are more or less the state of the art in elliptic curves. The keys are only 32 bytes and signatures are 64 bytes, with the same security as RSA-2048. The math is faster than RSA, too.
I also overhauled SecureDigest to add support for SHA-256, which was needed for implementing RSA signatures.