@jedisct1 Is this https://github.com/sodium-friends/sodium-native/blob/83ddae6de68d2aaeb876471a7b0d6899ca4eddf6/src/crypto_stream_xsalsa20_xor.c … something that would be worth preparing as a PR for libsodium? Idea is that you can do streaming crypto_stream where authentication is not an issue (used in the dat protocol which does auth by an merkel tree in the message)
-
-
Replying to @emilbayes
I’d rather not encourage people to use unauthenticated encryption. Seekable randombytes_buf_deterministic() would make more sense to achieve this.
1 reply 0 retweets 0 likes -
Replying to @jedisct1
I'd agree that with something like randombytes_buf_deterministic(buf, seed, offset) would be nice and fulfil the same purpose, except that I guess it would only expose a single algorithm (ietf chacha20)?
1 reply 0 retweets 0 likes -
Replying to @emilbayes
It’s hard to find a balance between fulfilling requirements of specific protocols, and avoiding bloat and confusion by providing 20 algorithms doing exactly the same thing.
1 reply 0 retweets 0 likes -
Replying to @jedisct1 @emilbayes
If many actual projects really need a specific algorithm to do what can already be achieved, the new algorithm can be considered. If it’s just for one isolated use case, I’d rather not add more bloat that no one else would use.
2 replies 0 retweets 0 likes
But that can be implemented as a distinct, small library. If only to stabilize the API and see how many people will use it (like what was done with blobcrypt and spake2 — I was excited about them, but nobody’s using them, so merging them would have been a bad idea after all).
-
-
Replying to @jedisct1
Ah yes, that's a good idea. I think that's the way I will do it. Thank you for your feedback :)
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.