Missing algorithms
newpavlov opened this issue · 36 comments
@newpavlov I have a locally working chacha20poly1305 crate I can push up, but I don't have permission.
It should be fairly trivial to implement both AES-GCM and AES-GCM-SIV once I have my implementation of POLYVAL working:
Ah, I forgot to add this repository to the team. Now it should work.
I'll throw in a request for XSalsa20Poly1305. I'm looking to replace magic-wormhole's libsodium dependency with something smaller, but I need to retain interoperability with the default libsodium secretbox implementation, which uses XSalsa20 and not XChaCha20.
AES-GCM and XSalsa20Poly1305 are now done 
I also have a WIP PR to merge the AES-SIV implementation from Miscreant
It would be very cool to add support for CAESAR competition winners:
https://competitions.cr.yp.to/caesar-submissions.html
Even though they are not widely used, they are considered the "best option if available" and they would give an edge to Rust, especially considering how easy cross-platform Rust is.
According to the page, ACORN and COLM are considered "second-choice" so I believe they should also come second in an order of priority. So the ciphers to implement first would be:
- Ascon
- AEGIS-128(/256?) and/or OCB
- Deoxys-II
Another suggestion would be XChaCha20-Poly1305.
The reason is that, if there is a lot of encryption/decryption with the same key, with standard ChaCha20 might be vulnerable to a nonce collision. A single collision is enough to break the authenticity provided by Poly1305.
The main difference between the two is that XChaCha20 uses 192 bits nonce instead of 64 bits nonce, which makes collisions completely impractical if properly generated. Since there is already a crate for ChaCha20 and XSalsa20, I guess it wouldn't be really hard to implement.
@zer0x64 it's already implemented in the chacha20poly1305 crate:
https://docs.rs/chacha20poly1305/latest/chacha20poly1305/struct.XChaCha20Poly1305.html
Oh, didn't saw that! Thanks for clarifying!
* [x] AES-GCM * [ ] AES-OCB * [ ] Deoxys-II
Can we remove AES-OCB from the list now? :)
@elichai I updated it to be AES-OCB3, presuming the implication was AES-OCB2 is broken
@elichai I updated it to be AES-OCB3, presuming the implication was AES-OCB2 is broken
Now I need to go read how big is the difference between OCB2 and 3 :D
The OCB2 breakage was a case of "missed it by that much" (it's insecure because the final encryption is XE instead of XEX).
To my knowledge OCB3 is still secure (as is OCB2, if you tweak the final encryption to be XEX like the rest of the cipher).
@bedax I would like to provide an implementation of Rogaway's STREAM construction, which has security proofs (i.e. "nOAE"), and isn't prescriptive about a wire format the way "secretstream" is. Personally I think it's unfortunate libsodium did not implement STREAM.
There are already several Rust implementations of STREAM floating around: one in Miscreant, one in sear, and another in rage.
STREAM has also been adopted by Google Tink.
Ideally I'd like to provide a crate which implements all of the "in the wild" variants, similar to what we've had to with the ctr crate.
If you're specifically looking for secretstream compatibility, that's something we can also consider, but personally I'd prioritize STREAM support over that.
Edit: we now have a crypto_secretstream crate here: https://github.com/RustCrypto/nacl-compat/tree/master/crypto_secretstream
The STREAM construction sounds particularly promising. Is it possible for RustCrypto's implementation to be generic over the Aead trait?
Yep, absolutely, it should be possible for it to be fully generic, including over things like nonce sizes
Edit: STREAM is now available in the aead crate: https://docs.rs/aead/latest/aead/stream/index.html
Brilliant, that would make a secretstream implementation unnecessary for me at least
Just wanted to recommend getting an implementation of the finalist from https://csrc.nist.gov/projects/lightweight-cryptography. I think getting the finalist from this into the crate will be pretty critical for some embedded devs. I'd guess Ascon is a likely candidate due to CAESAR, but we will have to see. I am of course willing to help with development effort after the finalist is selected. I think it would be a good algorithm to have.
I have a program, that is using the original chacha20poly130 construction with a 64 bit nonce of the libsodium. It would be great if a compatible implementation was available here, maybe after enabling the legacy feature as used for ChaCha20Legacy.
@kamulos cool, that should be a pretty simple PR if you'd like to add that functionality yourself. It would end up looking quite similar to xchacha20poly1305, but with ChaCha20Legacy as the Cipher.
For the record, I started working on a reference/unoptimized Deoxys implementation. I will open a WIP PR if I can get it working.
EDIT: PR opened :)
I didn't see it mentioned here, so I thought I'd mention it: The patents for OCB were abandoned last year (2021)
I'm no cryptographer, but someone just interested in what seems to be the "best" way of doing things, so I have some interest in seeing a AES-OCB3 crate.
Hey, I am currently in the process of finishing a generic, optimized implementation of COLM, which was the second choice for use-case "defense-in-depth" of the CAESAR competition. I am in close contact with one of the authors who can informally verify the correctness of my code.
Would this be interesting for RustCrypto?
The current implementation can be found here: https://github.com/Schmid7k/colm_rs
At the moment it is only an implementation of COLM0, meaning the COLM variant without intermediate tag generation, but I would be more than happy to extend it if needed.
In terms of features I only need to implement proper tag verification for the decryption procedure.
EDIT: Opened a PR!
Is there appetite for Pure 🦀 AEGIS w/ SIMD aes+sse3 ?
Supposedly even soft may supposedly be faster than AES-GCM where real speed is from using aes extension supposedly.
It seems there has been a bit movement w/ IETF in C/Zig world with Frank who also has rust with -sys to C
I would use it for DTLS - https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/
Is there appetite for Pure 🦀 AEGIS w/ SIMD aes+sse3 ?
Supposedly even soft may supposedly be faster than AES-GCM where real speed is from using aes extension supposedly.
It seems there has been a bit movement w/ IETF in C/Zig world with Frank who also has rust with -sys to C
I would use it for DTLS - https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/
I personally think that implementing either AEGIS or OCB (preferably both) would be the next step when it comes to AEAD since there's no primitive yet in this repo for use case 2 of CAESAR. One thing that I'd note here is that the AES round has already been exposed in the aes crate for use with Deoxys, which would make implementation of AEGIS(hybrid software + SIMD) easier.
Hi guys. Is anyone working on OCB3? If not, I'll give it a shot.
Ah, I see. Thanks. I'll look for another one then. I have time to spend on learning some more Rust, so any will do :) If you have any algorithm in mind that you are interested in having, just let me know.
The Todo list needs to be updated. The documentation says the reduced round XChaCha has already been implemented.
AEADs/chacha20poly1305/src/lib.rs
Lines 21 to 22 in 57ac6eb