-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
Below are frequently asked questions about XSTREAM:
A: All constructions in Miscreant were designed by Phil Rogaway, a highly respected cryptographer, and also have security proofs, whereas XSTREAM is a comparatively bespoke (albeit boring) construction. We felt it would be best to keep experimental algorithms out of Miscreant proper. XSTREAM additionally relies on X25519 and HKDF, cryptographic primitives not found in Miscreant, so we thought it best to not burden Miscreant users with the additional dependencies if they're only planning on using the library in a purely symmetric capacity.
2. Q: Can I use XSTREAM to build my own transport encryption protocol for encrypting network/VPN connections?
A: No, please don't do this. XSTREAM is designed to encrypt data-at-rest and is useful for things like encrypting files or database records. It is not intended or designed to be the basis of a transport encryption protocol, and there are already plenty of those. Please use TLS or Noise for transport encryption.
3. Q: Why is nonce reuse misuse resistance important if XSTREAM generates a random ephemeral key every time and the STREAM construction always selects unique nonces? Shouldn't that ensure nonces are never reused under the same key?
A: Though randomly generating an ephemeral key every time should theoretically prevent nonce reuse, random number generators can fail, particularly on IoT platforms which Miscreant and XSTREAM aim to target. For example, the internal state of a cryptographically secure random number generator may be duplicated, reset, and/or reused accidentally, resulting in generation of duplicate ephemeral keys. We strive to use secure OS-provided random number generators in this library which in theory should be continuously reseeded, but bugs happen and using a nonce reuse misuse resistant construction provides for a belt-and-suspenders approach.
Nonce reuse misuse resistance is important because constructions like crypto_box(), despite sometimes being described as "misuse resistant", fail catastrophically in these conditions, leaking the XOR of the plaintexts and also leaking the Poly1305 authentication key. For more information, see the Miscreant Wiki page on nonce reuse misuse resistance.
A: The Noise Protocol is quite interesting and suitable to the same problem domain, and has received wide deployment via WhatsApp and the WireGuard VPN software, as well as academic scrutiny and analysis via automated model checking and other formal methods. There are also more mature and better documented libraries for many languages.
That said, while Noise is fairly simple (especially compared to TLS), XSTREAM is still dramatically simpler, albeit not suitable for the same purposes. Where Noise is designed to be usable as a transport encryption protocol, XSTREAM is not and is best suited for incremental data-at-rest encryption, such as encrypting files or database records. Noise is also suitable for these data-at-rest encryption cases, but we would like to experiment with what a minimalistic construction for this purpose would look like.
A: XSTREAM is inspired by the crypto_box() construction from NaCl (a.k.a. Curve25519XSalsa20Poly1305), and uses a very similar key exchange algorithm, with HKDF in XSTREAM taking the place of HSalsa20 in crypto_box(). A streaming variant of crypto_box() can also be found in libsodium. We think the crypto_box() construction has proven itself popular among developers and has received enough scrutiny to serve as the basis for the design in XSTREAM.
We've received bits of feedback from cryptographers but the design has not been thoroughly reviewed. If you are a cryptographer or other security-oriented academic interested in this, please get in touch.
A: Only if you pronounce NaCl as "salt". Hopefully the answer is no.
XSTREAM was created by Tony Arcieri.