FR: Non-cryptographer friendly opinionated suite

[EyeCon]

Based on the discussion in Nim Discord server, #security channel:

It would be very nice to have a suite of fundamentals to be used non-experts with some good defaults, to avoid mistakes with the fundamental operations.

In essence, I think the following would be a complete suite:

• Sign/verify
• AEAD
• Maybe encrypt for more than one receiver?
• Key derivation function (this would normally be an internal operation for the above, but might be useful to use a weak secret like a password for other purposes)
• Secure password hashing
• If possible: PAKE with e.g. OPAQUE
• If possible: ZKPP

[mratsim]

Quick ideas that would also be in line with some of the stuff I'd like to do would be:

• Sign/verify: Ristretto255. It's one of the suite for OPAQUE. It's also used in Zero-knowledge proofs scheme with Bulletproofs. I would need strong coffee for all that stuff. Oh, and libsodium also uses it and the Signal protocol as well (unless they use plain X25519). Plenty of vectors and implementations reviewed and tested as well for differential fuzzing.
• AEAD: a toss-up between ChaCha20-Poly1305 and AES-GCM. I've seen both in Status libraries:
  • AES-GCM: https://github.com/status-im/nim-eth/blob/05ef9a8/eth/p2p/discoveryv5/encoding.nim#L48-L52
  • ChaCha20-Poly1305: https://github.com/status-im/nim-libp2p/blob/58f383e/libp2p/crypto/chacha20poly1305.nim
  • Both are useful for QUIC as well which we will need at Status
    • https://github.com/status-im/nim-quic
    • https://datatracker.ietf.org/doc/html/rfc9001#section-5.4.3 and https://datatracker.ietf.org/doc/html/rfc9001#section-5.4.4
• Encrypt for more than one receiver? As in a session key shared between a set of people? I think that's one of the hardest problem to solve if those receivers may come and go and we need to asynchronously revoke or add new receivers. Even Signal for their group messages negotiated keys 1<->1 and couldn't provide proofs that within a group the same message was actually sent to all people.
  • There is this draft that is working to solve this problem: https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-12
  • That blog post looked interesting for a practical solution (that doesn't seem to scale but well at least it's in production): https://signal.org/blog/how-to-build-encrypted-group-calls/
  • Maybe the Vacp2p/Waku team (messaging protocol researcher at Status) will also come up with an interesting scheme for encrypted group chats since it's one of our core problems (Protocol request: Direct group communication protocol for low-latency applications (<100ms) vacp2p/rfc#446)
• KDF: Will be HKDF, the fact that I have seen it implemented:
  • not once: https://github.com/status-im/nim-blscurve/blob/0237e4e/blscurve/eth2_keygen/hkdf.nim
  • not twice: https://github.com/status-im/nim-eth/blob/b7ebf8e/eth/p2p/discoveryv5/hkdf.nim
  • but thrice: https://github.com/status-im/nim-libp2p/blob/58f383e/libp2p/crypto/hkdf.nim
    implemented by different people should be a good indication that it's needed.
    Also I have seen it in OPAQUE spec.
• Password hash: Argon2 and maybe Scrypt. The first one is state-of-the-art, the second one is used everywhere for blockchain keystores (example https://eips.ethereum.org/EIPS/eip-2335#scrypt-test-vector)
• OPAQUE is very interesting and the IETF working group is quite active so why not. Would definitely need that Ristretto
• ZKPP sure, but I don't see an IETF RFC defining such protocol, or even litterature. Most points back to PAKE protocols like SRP (example: https://crypto.stackexchange.com/questions/1467/zero-knowledge-password-proof), but then it's superceded by OPAQUE.
  • I do think M-Pin would qualify though:
    • M-Pin + TLS:
      • Blog: https://miracl.com/blog/m-pin-a-multi-factor-zero-knowledge-authentication-protocol/
      • Paper: https://miracl.com/assets/pdf-downloads/mpin4.pdf
    • M-Pin full (doesn't need TLS):
      • Blog: https://miracl.com/blog/m-pin-full-technology-version-3.1/
      • Paper: https://miracl.com/assets/pdf-downloads/mpinfull_3.1.pdf
        and it's trivial to add as Constantine supports all the primitives for it and the reference code is there:
      • https://github.com/miracl/core/blob/2ef7bd16/c/mpin256.c

[oskarth]

Related vacp2p/rfc#494