forked from cheng/wallet
74 lines
4.4 KiB
Markdown
74 lines
4.4 KiB
Markdown
|
---
|
|||
|
|
title: Review of Cryptographic libraries
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Noise Protocol Framework
|
|||
|
|
|
|||
|
|
[Noise](https://noiseprotocol.org/) 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](./building_and_using_libraries.html#instructions-for-libsodium)
|
|||
|
|
|
|||
|
|
# I2P
|
|||
|
|
|
|||
|
|
The [Invisible Internet Project](https://geti2p.net/en/about/intro) 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
|
|||
|
|
|
|||
|
|
[Amber](https://github.com/bernedogit/amber)
|
|||
|
|
|
|||
|
|
Not as fast and efficient as libsodium, and further from Bernstein. Supports base 58, but [base58check](https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart) 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.
|
|||
|
|
|
|||
|
|
[Curve25519](https://github.com/msotoodeh/curve25519)
|
|||
|
|
|
|||
|
|
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](https://github.com/floodyberry/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](schnorr-signatures.pdf), 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](https://www.ietf.org/archive/id/draft-ford-cfrg-cosi-00.txt) [using ED25519](https://crypto.stackexchange.com/questions/50448/schnorr-signatures-multisignature-support#50450)
|
|||
|
|
|
|||
|
|
Amber library packages all these in what is allegedly easy to incorporate form, but does not have Schnorr multisignatures.
|
|||
|
|
|
|||
|
|
[Bernstein paper](https://ed25519.cr.yp.to/software.html).
|
|||
|
|
|
|||
|
|
The fastest library I can find for pairing based crypto is [herumi](https://github.com/herumi/mcl).
|
|||
|
|
|
|||
|
|
How does this compare to [Curve25519](https://github.com/bernedogit/amber)?
|
|||
|
|
|
|||
|
|
There is a good discussion of the performance tradeoff for crypto and IOT in [this Internet Draft](https://datatracker.ietf.org/doc/draft-ietf-lwig-crypto-sensors/), 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.
|