Missing algorithms

[newpavlov]

• [ ] AEGIS
• [x] AES-GCM
  • [ ] XAES-256-GCM
• [x] Deoxys-II (#311)
• [x] Multilinear Galois Mode
• [x] OCB3 (#587)
• [x] Reduced round XChaChaPoly
  • [x] XChaCha8Poly1305
  • [x] 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:

https://github.com/RustCrypto/MACs/pull/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 :shipit:

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

[bedax]

The STREAM construction sounds particularly promising. Is it possible for RustCrypto's implementation to be generic over the Aead trait?

[tarcieri]

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

[bedax]

Brilliant, that would make a secretstream implementation unnecessary for me at least

[2over12]

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.

[kamulos]

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.

[tarcieri]

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

[zer0x64]

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

[zer0x64]

Deoxys-II has been implemented in deoxys in https://github.com/RustCrypto/AEADs/pull/311 and has been released as of https://github.com/RustCrypto/AEADs/pull/328 .

[Absolucy]

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.

[pinkforest]

Is there appetite for Pure :crab: 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/

[zer0x64]

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.

[dfabregat]

Hi guys. Is anyone working on OCB3? If not, I'll give it a shot.

[tarcieri]

See #550 for OCB3

[dfabregat]

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.

[siv2r]

The Todo list needs to be updated. The documentation says the reduced round XChaCha has already been implemented. https://github.com/RustCrypto/AEADs/blob/57ac6eb8038cf0d2b4efd24821fc05601ddda173/chacha20poly1305/src/lib.rs#L21-L22

[pinkforest]

Re: AEGIS - Frank has brought this alive - https://github.com/jedisct1/rust-aegis/

It has pure-rust as well but it's via feature - have asked whether it would be ok to move to cfg() to compose it in.

Might be worthwhile to investigate intrisinics / SIMD / inline asm for that from libaegis or smth

[AaronFeickert]

Looks like there is now a specification for XAES-256-GCM. Might it be useful to include?

[SergioBenitez]

Really interested in XAES-256-GCM. Are there efforts to implement it in aes, and if not, would such efforts be welcome?

[tarcieri]

@SergioBenitez it should probably go in aes-gcm or its own crate

[SergioBenitez]

An xaes-gcm crate sounds apt. Would an implementation contribution be welcome?

[tarcieri]

Sure