It seems there is a difference between \"streaming\" in cryptographic sense (as

Question

It seems there is a difference between "streaming" in cryptographic sense (as in CTR) and "streaming" in general programming sense (as in "accept a file larger than RAM from socket and save it on disk"). It shows when people try to apply AEAD (or in general authenticated encryption) schemes to something like Java's InputStreamReader (e.g. authentication is broken or not enforced enough). To do streaming in a latter sense it would be very useful to have AEAD scheme that provides "intermediate" authentication, that is, for block of encrypted message it should be known if it's genuine up to the point. Granted, later we can discover that there were some meddling and revert all the work already done (or just skip affected part), but it would be simpler compared to what is, in a sense, two-stage scheme (receive an entire message and only then verify it). Is there such schemes out there? Am I missing something that makes the proposed arrangement terribly insecure?

Explanation / Answer

Yes there are such schemes.

However they aren't standardized by any means yet.
The schemes I'm talking about take part in CAESAR-competition.
If you wait ~1 week (hopefully) you'll see if any mode / cipher makes in in the second round.
This paper provides you with a good overview over the ciphers.
The four ciphers you need are:

+ ICEPOLE (Sponge based)
+ KETJE (Sponge based)
+Keyak (Sponge based)
+TriviA-ck (Streamcipher based)

This schemes can be used. But I'd strongly recommend against using them before CAESAR-competitions has further advanced (a few years?). Until then splitting a message stream into pieces with own tags + IVs seem to be the only method one can think of. To ease up IV management, one could use Message numbers as nonces.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.