Missing algorithms

[newpavlov]

• AEGIS
• AES-GCM
  • XAES-256-GCM
• Deoxys-II (#311)
• Multilinear Galois Mode
• OCB3 (#587)
• Reduced round XChaChaPoly
  • XChaCha8Poly1305
  • XChaCha12Poly1305

[tarcieri]

@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:

RustCrypto/MACs#13

[newpavlov]

Ah, I forgot to add this repository to the team. Now it should work.

[warner]

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.

[tarcieri]

AES-GCM and XSalsa20Poly1305 are now done

I also have a WIP PR to merge the AES-SIV implementation from Miscreant

[zer0x64]

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

[zer0x64]

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.

[tarcieri]

@zer0x64 it's already implemented in the chacha20poly1305 crate:

https://docs.rs/chacha20poly1305/latest/chacha20poly1305/struct.XChaCha20Poly1305.html

[zer0x64]

Oh, didn't saw that! Thanks for clarifying!

[elichai]

* [x]  AES-GCM

* [ ]  AES-OCB

* [ ]  Deoxys-II

Can we remove AES-OCB from the list now? :)

[tarcieri]

@elichai I updated it to be AES-OCB3, presuming the implication was AES-OCB2 is broken

[elichai]

@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

[tarcieri]

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]

Are there any plans for a secretstream implementation, similar to, or preferably compatible with libsodium/orion?

[tarcieri]

@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