Noise properties and protocol comparisons - noiseprotocol/noise_spec GitHub Wiki

Comparison to TLS

As a quick intro to Noise's design, consider Noise pipes compared to TLS:

  • Encrypted handshake: The TLS handshake is in the clear, which leaks the parties' identities. Aside from ephemeral public keys, the Noise handshake is encrypted.
  • Low latency handshake: TLS specifies 2 round trips before clients can start sending data. Noise requires 1 round trip.
  • Forward secrecy: Even when TLS is used with ephemeral Diffie-Hellman, its forward secrecy is limited: compromise of an endpoint to an active connection will compromise previous traffic sent or received by that endpoint. In contrast, whenever the Noise ChaCha20/Poly1305 ciphersuites send or receive ciphertext they destroy the keys for that ciphertext.
  • Simplicity: Noise is simpler than TLS. Noise omits many features that have resulted in TLS security flaws (version and ciphersuite negotiation, compression, renegotiation, chaining CBC IVs, MAC-then-encrypt, error alerts, etc.).
  • All Diffie-Hellman (no signatures): Using TLS with ephemeral ECDH requires signatures. Noise relies only on ECDH (no signatures). This yields a simpler and more robust protocol, reduces bandwidth, and avoids creating hard-to-deny evidence of who has communicated with who.

Noise properties in more detail

Box properties

When used for file or record encryption, Noise boxes have the following properties:

  • Sender forward secrecy: After encryption of a Noise box, only the recipient can decrypt it (the sender cannot).
  • Deniable: The recipient of a Noise box can authenticate the sender, but cannot produce digitally-signed evidence binding the sender to anything.
  • Identity hiding: Noise boxes reveal no information about the sender or recipient to a 3rd-party observer.
  • Padded: Noise ciphertext can be padded to avoid leaking plaintext lengths.
  • Built on "Encrypt-then-MAC" authenticated encryption: Any tampering with ciphertext will cause the recipient to reject the ciphertext prior to decryption.

Pipe properties

Noise pipes are built out of Noise boxes, so inherit the above properties and add some additional ones:

  • Full forward secrecy: Compromise of long-term private keys does not compromise old pipes.
  • Resistant to key-compromise impersonation: Even if one party's private key is compromised, the compromised party is still capable of verifying other parties' identities in a Noise pipe.
  • Efficient handshakes: Handshake computation cost is similar to protocols with similar properties (e.g. SIGMA-I). Clients are able to send data after the first round-trip.

Comparison to other protocols

"Box"-like protocols

  • NaCl: NaCl crypto_boxes lack sender forward secrecy and don't convey the sender's identity.
  • PGP: PGP signed-then-encrypted messages are complicated, lack "Encrypt-then-MAC" encryption, lack deniability, allow surreptitious forwarding, use outdated crypto (ElGamal, DSA, CAST5, CFB, etc), and usually have a sub-128-bit security level.
  • KeyCzar: KeyCzar doesn't have public-key authenticated and encrypted messages, nor does it offer elliptic-curve encryption.

"Pipe"-like protocols

  • CurveCP: CurveCP lacks resistance to key-compromise impersonation for the server. Also, a compromised ephemeral client key can be used permanently for impersonating the client. CurveCP requires the client to know the server's key prior to connecting, so trust models based on server certificates or "Trust-on-First-Use" are not directly supported.
  • SSH: SSH is complicated, lacks deniability for the client when authenticating using signatures, and lacks in-connection forward secrecy.
  • ZRTP: ZRTP is complicated, lacks identity-hiding, lacks in-connection forward secrecy, lacks deniability when authenticating using signatures, and requires at least 3 round-trips for a handshake.
  • QUIC: QUIC has the innovative feature of allowing "zero-latency" initial connections if the client knows recent data about the server. However, this feature costs QUIC a small reduction in forward-secrecy for the initial RT of communication, and a bit more computation and complexity during the handshake.
  • OTR: OTR usually has a sub-128-bit security level, and has 1.5 round-trips of latency for the handshake. OTR has some minor issues regarding deniability and forward secrecy:
    • OTR's use of signatures for key agreement makes deniability more complex and weaker than it should be (firstly: transcripts cannot be generated arbitrarily, but must be modified from an existing validly-signed transcript, necessitating malleable ciphertexts and publication of MAC keys; secondly: signatures bind signers to received Diffie-Hellman values).
    • OTR's use of constantly-updating Diffie-Hellman values provides sub-optimal forward secrecy with regard to old ciphertexts. Since older DH keys cannot be discarded until the new key is acknowledged, forward secrecy does not apply to any old ciphertext created by a party but not yet acknowledged.

Home

Next (Boxes)

⚠️ **GitHub.com Fallback** ⚠️