ahdinosaur/secret-channel

🤫 A protocol for an authenticated and encrypted message stream

"Secret Channel" 🤫

Streaming authenticated encryption using ChaCha20-Poly1305 (RFC 8439) (or other AEADs).

A protocol for a secure message stream, after you've done a secure key exchange.

(Note: This protocol has not been audited to be safe. Use at your own risk.)

Specification

See SPEC.md

Packages

JavaScript

Protocol: secret-channel

Pull Stream: pull-secret-channel

Node Stream

TODO

Rust

Protocol

TODO

Async Stream

TODO

secret-channel's Issues

Key usage limits and re-keying

Looks like AEAD algorithms have usage limits: https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-limits-07.html

ChaCha20-Poly1305's limit is 2^100. Wait... that's plenty good.

But @noble/ciphers says 2^46: https://github.com/paulmillr/noble-ciphers#encryption-limits. Why the difference?

Will look into this more. If the limit is low enough, we could set a threshold to automatically re-key.

The idea would be to have the 96-bit nonce constructed similar to STREAM and libsodium's secretstream:

• 64-bits are a preset (random) nonce
• 32-bits are a incrementing counter starting at 0.
• When the 32-bit counter overflows, automatically re-key.

Start with random nonce and increment?

Rather than start our nonce with zero, there's a possible security gain (for the far-away future, since current 192-bit keys are considered secure even with simple counting nonces starting from zero) if we start our nonce with a preset (random) value.

This is what secret-handshake and pull-box-stream did. https://ssbc.github.io/scuttlebutt-protocol-guide/#box-stream

I'm not super convinced it's worth it. But maybe I'm wrong.

I see also that TLS has a counter that starts at zero, but XOR's that counter with a preset (random) value to construct the nonce.

The Security of ChaCha20-Poly1305 in the Multi-user Setting

https://eprint.iacr.org/2023/085.pdf

Big endian vs little endian

Not sure whether to use big endian or little endian.

My understanding is most CPUs are LE (so LE is more efficient), but network protocols are "supposed to be" BE. https://developer.mozilla.org/en-US/docs/Glossary/Endianness

One idea is we use little endian for the incrementing nonce (used internally), and big endian for the content length (sent over the network). Little endian for the nonce helps make incrementing with libsodium easy, because libsodium provides a increment function which increments a little-endian buffer.

Goodbye could just be a zero length header

Since content with zero-length should be disallowed anyways.

And then we skip all the type bit voodoo.