Open NeilMadden opened 3 months ago
Thanks for finding this issue in our documentation!
I agree with you. Tink implements (with some modifications) the STREAM construction, and not CHAIN. And as stated in Theorem 2 in https://eprint.iacr.org/2015/189.pdf, this only archives nOAE, not OAE2.
I don't think there was ever the intention of implementing OAE2, so I think this is a bug in Tink's documentation and not in the implementation. Tink's StreamingAEAD API can't really achieve OAE2, because it offers random-access decryption, which can't be efficiently implemented for OAE2.
Note that a very good analysis of Tink's implementation of streaming AEAD was done in https://eprint.iacr.org/2020/1019.pdf.
I have now fixed this in: https://github.com/tink-crypto/tink-java/commit/abe69c0d499daf8ce0b1471c48035088bbe3c6c8
I've also fixed it for the other languages, and on the dev site: https://developers.google.com/tink/streaming-aead.
Let me know if there are any other place I missed.
The description of the StreamingAEAD primitive says that all implementations are OAE2-secure, but the implementation is of the STREAM construction that is only nOAE-secure (from section 7 “Weakening OAE2” of the linked paper).
The CHAIN construction in section 6 of the same paper does achieve OEA2 security, but only if the underlying AEAD is a pseudorandom injection such as SIV mode or AEZ. IMO you should treat this as a docs bug and relax the security goal to nOAE rather than changing the implementation.