[noise] Questions and feedback

[Trevor Perrin]

On Thu, Sep 12, 2019 at 5:42 AM Mike Hearn <mike at r3.com> wrote:
>
> Hello,
>
> We're experimenting with Noise in a commercial product designed for enterprise use cases, where small size / easy auditability of the codebase is important and we can sacrifice TLS compatibility.
>
> Firstly, thanks! Noise is very nicely done, the spec is easy to read and the mix'n'match approach is a good fit for what we need. We're planning to use a derivative of the Noise-Java library, so thanks to Rhys Weatherley too.
>
> Having read the specs I had a few questions.

Hi Mike,

> Ciphersuites.
>
> There's a requirement to support two different symmetric cipher suites. The spec gives justifications for many decisions, but curiously does not justify the choices here. For instance, it specifies the use of BLAKE2 rather than SHA3. An obvious question a security auditor might have is why the backup option for SHA2 is not the winner of the NIST competition but rather a runner-up. The spec says "BLAKE2 is fast and similar to ChaCha20", but that seems somewhat light as a justification - does the Noise community believe there's no reason to ever use SHA3, for example?


You could certainly use SHA512 as a backup to SHA256 (or vice versa)
to achieve your "two different symmetric cipher suites" goal.

BLAKE2 being "fast and similar to ChaCha20" is pretty much why we
chose it, perhaps that's a light justification, but it makes
implementation easier.

I don't have anything against SHA3.  There's a lot of constructs based
on the same (flexible) Keccak primitive: SHA3, KMAC, SHAKE, cSHAKE,
TupleHash, Kangaroo12, etc., so choosing a construct in the Keccak
family is a bit complicated, and just taking SHA3 with HMAC gives you
something a bit slow and overengineered. You can find some discussions
in the mailing list about a "Stateful Hash Object" API and
constructions which would be more tailed towards stateful hashing in
Noise.  If you wait long enough maybe we'll figure out the most
elegant Keccak-based approach for Noise.


> Although I understand the desire to have backup options, as far as I know there are currently no clouds on the horizon for AES or SHA2 and negotiation/fallback is a rather complex feature that has created problems in the past with TLS. Because part of the value of Noise to me is the small size of an implementation (and ease of convincing people it's correct), it's tempting to use only AESGCM/SHA256 and spin an entirely new rev of the protocol if one day these primitives start to break (e.g. different port number), rather than do negotiation on the fly. This is doubly tempting because the product in question is designed for conservative organisations that tend to have whitelists of "approved" cryptography, and ChaCha20-Poly1305 is unlikely to be on them yet. Yes, I know Chrome already supports these and they're being widely deployed. If only "Chrome does it" was always a winning argument :(
>
> A common justification for ChaCha20 over AES is that AES is hard to implement well in software. But in this specific product, all the CPUs we'll run on have AES hardware acceleration, so this is not a concern for us.
>
> If we instantiate a protocol with only AES/SHA2, are there any compelling reasons to believe that will create big problems later? Given the long history of strength for both AES and SHA2 my guess is my customers will request a move to post-quantum crypto before caring about ChaCha20/BLAKE2.

All seems reasonable to me, including just rev'ing the protocol for
new crypto, assuming your environment allows that.


> With respect to the DH curve, the spec says: "The 25519 DH functions are recommended for typical uses, though the 448 DH functions might offer extra security in case a cryptanalytic attack is developed against elliptic curve cryptography".
>
> This phrasing leads to an obvious question - if Curve448 might offer extra security and has no other downsides then why is it not the default? Is it slower?

Slower, and less widely available in libraries.

Trevor