Shift StreamingAead to use RustCrypto aead::stream module

[tarcieri]

FYI, there's an open PR to add a stream module to the RustCrypto aead crate which StreamingAead could potentially benefit from:

RustCrypto/traits#436

In particular I think it'd be nice if rage and tink-rust could potentially share code, particularly around things like async and/or parallel stream readers/writers.

Anyway, heads up we're working on some common abstractions for this sort of thing and would love your input, in particular if you think it would be helpful for things like StreamingAead, and if you have any concerns about the proposed design.

I think age and Tink (in all forms) might also use a common "flavor" of STREAM, although I haven't confirmed that.

Sidebar: STREAM isn't actually OAE2, but rather "nonce-based OAE" (nOAE). CHAIN is required for OAE2. (Edit: I now see the noncebased streaming module, never mind)

[daviddrysdale]

I'd be very happy if tink-rust could defer the cryptographic heavy lifting to another (RustCrypto) crate for StreamingAead, same as it does for ≈ all the other primitives!

However, (as you say) it would depend on everything needing/using the exact same variants, and I've not yet looked into the details either. (To put it another way: I'd like the Tink cross-language tests to keep passing.)

BTW, did you see https://eprint.iacr.org/2020/1019.pdf? The intro includes a helpful description of Tink's adaptation of STREAM.

[tarcieri]

Upon examining Tink it appears to use the original Rogaway paper definition of STREAM, which is definitely something worth supporting.

I can and should add support for it to RustCrypto/traits#436, which otherwise implements a slightly different version with a small optimization/ergonomics improvement, but that's why it defines the StreamPrimitive trait to allow different "flavors" of STREAM which can enable higher-level things like parallel and/or async encryptors/decryptors to be generic over STREAM "flavors".

BTW, did you see https://eprint.iacr.org/2020/1019.pdf? The intro includes a helpful description of Tink's adaptation of STREAM.

Nice writeup, thanks!

It appears Tink operates at a much higher level and defines its own STREAM framing, in addition to specifying STREAM "ciphersuites" which use HKDF to derive a STREAM-specific key.

That's all well and good and for the best. That said, the traits and implementations thereof in RustCrypto/traits#436 are much, much lower-level and I think should fit within Tink's framework just fine.

[tarcieri]

FYI, the new stream module is now available:

https://docs.rs/aead/0.4.1/aead/stream/index.html

The StreamBE32 type should implement the particular formulation of STREAM used by Tink:

https://docs.rs/aead/0.4.1/aead/stream/struct.StreamBE32.html