<div dir="ltr">I'm pleased to announce the initial release of XSTREAM: a misuse-resistant public key cryptography library built on top of Miscreant which provides incremental/streaming encryption support:<div><br></div><div><a href="https://github.com/miscreant/xstream">https://github.com/miscreant/xstream</a><br><div><div><br></div><div>FAQ available here:</div><div><br></div><div><a href="https://github.com/miscreant/xstream/wiki/FAQ">https://github.com/miscreant/xstream/wiki/FAQ</a><br></div><div><br></div><div>XSTREAM is based on the STREAM construction, described here:</div><div><br></div><div><a href="https://github.com/miscreant/miscreant/wiki/STREAM">https://github.com/miscreant/miscreant/wiki/STREAM</a><br></div><div><br></div><div>## Supported Languages</div><div><br></div><div>Like Miscreant, XSTREAM is available for 5 different programming languages: Go, JavaScript/TypeScript, Python, Ruby, and Rust.</div><div><br></div><div>Miscreant has also recently been ported to .NET/C# and we hope to have a C# XSTREAM available soon too.</div><div><br></div><div>## What is it useful for?</div><div><br></div><div>XSTREAM is intended for encrypting data-at-rest while supporting incremental processing, such as encrypting files, database records, or other "blobs" of data processed a chunk-at-a-time, so if you're encrypting a 100GB file you don't need 100GB of RAM to encrypt it, but can instead encrypt it in smaller chunks with a size of your own choosing. The underlying STREAM construction ensures data is both authenticated and processed in-order, with out-of-order or truncated data manifesting as a MAC verification failure.</div><div><br></div><div>It is NOT designed to be a transport encryption protocol used to secure data-in-motion, e.g. as part of an interactive network service. For those use cases, we recommend you use TLS or Noise.</div><div><br></div><div>## Construction</div><div><br></div><div>XSTREAM's encryptor accepts a static X25519 public key as an argument. Internally it randomly generates an ephemeral secret scalar value (i.e. X25519 secret key), performs elliptic curve Diffie-Hellman, then uses the resulting shared secret as an input to HKDF-SHA-256, which it uses to derive a symmetric key for use with STREAM (using AES-128-PMAC-SIV as the default cipher).</div><div><br></div><div>Conceptually XSTREAM is similar to NaCl's crypto_box() with an ephemeral key, or libsodium's crypto_box_seal() which handles generating the random ephemeral secret key for you. However, XSTREAM gracefully tolerates things like RNG failures thanks to its nonce reuse misuse resistance[1], whereas ciphers like (X)Salsa20 and (X)ChaCha20 leak the XOR of the plaintexts under these conditions, and the Poly1305 authenticator leaks the authentication key.</div><div><br></div><div>However, before you choose XSTREAM over crypto_box()/crypto_box_seal(), please see the warning below.</div><div><br></div><div>[1]: XSTREAM is built on the misuse resistant AES-SIV and AES-PMAC-SIV symmetric ciphers as implemented in Miscreant. You can read more about it here: <a href="https://github.com/miscreant/miscreant/wiki/Nonce-Reuse-Misuse-Resistance">https://github.com/miscreant/miscreant/wiki/Nonce-Reuse-Misuse-Resistance</a></div><div><br></div><div>## WARNING</div><div><br></div><div>This is v0.1 of an unreviewed cryptography library. It should go without saying that you shouldn't use it for anything serious yet.</div><div><br></div><div>That said, even if you're feeling a bit YOLO and want to use it anyway, there's good reason not to yet: the design is not frozen and likely to change. There is presently an open issue which is likely to result in breaking changes:</div><div><br></div><div><a href="https://github.com/miscreant/xstream/issues/15">https://github.com/miscreant/xstream/issues/15</a></div><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div></div>