Loup Vaillant

Thanks for your thoughts, they do clarify a few things for me. - Fix1 is a deal breaker because of embedded. I also agree that we don’t want yet another...

> I would recommend fix 2 given that it seems to be the most common approach. It's also the only safe one that's not an instant deal breaker in many...

> "we" back into the manual. Sorry, that was not on purpose. Feel free to correct it in a PR if you want, otherwise I can rephrase it out.

OK, I've written a quick (untested) implementation for the safe signing API. Here's what we need: ```C void crypto_sign_key_pair(u8 secret_key[64], u8 public_key[32], u8 seed[32]) { // Tolerate overlap between seed...

And cryptographers worry about quantum computing… Tentative answers: 1. Not before someone else (Libsodium, Dalek, libdecaf…) lays out a clear action plan. 2. This is probably unfixable, even in theory....

Okay, I found why people worry about commitment in the context of encrypted messages. Following [this paper about partitioning oracles](https://eprint.iacr.org/2020/1491.pdf), Age decided to mitigate the attack by [limiting the size...

Hmm, I'm not sure we can meaningfully hide message sizes from traffic analysis in an interactive protocol, so I'm not sure Scuttlebutt's workaround really works: when you're sending a message...

Seems like I finally have a design worth considering ([latest version](https://github.com/LoupVaillant/Monocypher/tree/stream)). Here's the API: ```C typedef struct { uint32_t counter; // MSB of the ChaCha20 counter uint8_t key[32]; uint8_t nonce[8];...

@fscoto: 1. No it's not. I considered it, but I disagree pretty strongly with Libsodium's design choices on the matter: its streaming interface is incompatible with its monolithic interfaces, and...

Added some tests, and refined the design. I have managed to lift the size limits of chunks, at the cost of an increased rekey overhead (the automatic rekey occurs every...