4.4 KiB
| title |
|---|
| Review of Cryptographic libraries |
Noise Protocol Framework
Noise is an architecture and a design document, not source code. Example source code exists for it, though the [C example] (https://github.com/rweather/noise-c) uses a build architecture that may not fit with what you want, and uses protobuf, while you want to use Cap’n Proto or roll your own serialization. It also is designed to use several different implementations of the core crypto protocols, one of them being libsodium, while you want a pure libsodium only version. It might be easier to implement your own version, using the existing version as a guide. Probably have to walk through the existing version.
Libsodium
I2P
The Invisible Internet Project does a great deal of the chat capability that you want. You need to interface with their stuff, rather than duplicate it. In particular, your wallet identifiers need to be I2P identifiers, or have corresponding I2P identifiers, and your anonymized transactions should use the I2P network.
They have a substitute for UDP, and a substitute for TCP, and your anonymized transactions are going to use that.
Amber
Not as fast and efficient as libsodium, and further from Bernstein. Supports base 58, but base58check is specifically bitcoin protocol, supporting run time typed checksummed cryptographically strong values. Note that any value you are displaying in base 58 form might as well be bitstreamed, for the nearest match between base 58 and base two is that 58^7^ is only very slightly larger than 2^41^, so you might as well use your prefix free encoding for the prefix.
Thirty two byte public key, thirty two byte private key.
Key agreement is X25519
Signing is ED25519. Sixty four byte signature.
Trouble is that amber does not include Bernstein’s assembly language optimizations.
ED25519/Donna does include Bernstein’s assembly language optimizations, but is designed to compile against OpenSSL. Probably needs some customization to compile against Amber. Libsodium is designed to be uncontaminated by NSA.
ED25519 does not directly support Schnorr signatures, being nonprime. Schnorr signatures can do multisig, useful for atomic exchanges between blockchains, which are multisig, or indeed arbitary algorithm sig. With some cleverness and care, they support atomic exchanges between independent block chains.
explanation of how to do Schnorr multisignatures using ED25519
Amber library packages all these in what is allegedly easy to incorporate form, but does not have Schnorr multisignatures.
The fastest library I can find for pairing based crypto is herumi.
How does this compare to Curve25519?
There is a good discussion of the performance tradeoff for crypto and IOT in this Internet Draft, currently in IETF last call:
From the abstract:.
This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for small devices and presents some preliminary experiences with those libraries for message signing on small devices. Lastly, the memo discusses trade-offs involving different types of security approaches.
The draft contains measurement and evaluations of libraries, allegedly including herumi. But I don’t see any references to the Herumi library in that document, nor any evaluations of the time required for pairing based cryptography in that document. Relic-Toolkit is not Herumi and is supposedly markedly slower than Herumi.
Looks like I will have to compile the libraries myself and run tests on them.