Support for AES mode ECB or CTR?

[algesten]

Hi!

I'm not a crypto developer, so I might get some terminology wrong. I maintain str0m, a Sans-IO WebRTC library in Rust. For a long time, we wanted to replace OpenSSL, ideally with a Rust native solution. Recently we made some headway, and briefly tried RustCrypto, but decided it's not fast enough yet. So the decision is currently aws-lc-rs (which isn't really native, I know). I got the question whether we considered Graviola.

In WebRTC, DTLS is used to extract keying material for SRTP. That is later used to derive keys using AES ECB rounds. These keys are then used to secure the SRTP traffic with AES_GCM_128/256. The keys need to match that of the remote peer's (which often is a browser), and I don't believe there is a way to do this apart from ECB.

Is ECB something Graviola will support in the future? aws-lc-rs warns against it, so I understand it might be controversial providing the tools to shoot myself in the foot.

Regarding CTR, it's in some respects a lesser issue. A common fallback for older browsers is SRTP_AES128_CM_SHA1_80, which would require counter mode. However it might be we could stop supporting this.

[conradludgate]

For what it's worth, graviola doesn't actually implement AES - it only supports hardware implementations. So to at least unblock the efforts to move away from openssl you could instead use one of the RustCrypto implementations - https://docs.rs/ecb/latest/ecb/.

Graviola's benchmarks make RustCrypto AES look very slow. I'm not sure why that is, but I hope that one day RustCrypto might have better optimisations here, I see no fundamental reason for it to be that much slower.

[algesten]

Thanks!

In the end, we decided to have many crypto backends, Graviola is a potential future such. For rust-crypto we are using the aes crate for the ECB rounds.