In regards to NaCl, I asked DJB he had any intent to add a streaming API to an authenticated cipher. His response was obvious in retrospect, that one should never release a decrypted plaintext before verifying the authenticator.
However, this got me to thinking. Streaming is important — for instance, when working with extremely large datasets. Is it possible, or even advisable, to mimic a streaming interface?
One simple approach would be to chunk the data every certain number of blocks. Once you've received enough blocks, output the IV and a complete ciphertext into the cryptostream. When you've received the next set of blocks to complete a chunk, generate a new IV and repeat. To decrypt, take the first block of the cryptostream and consider this to be the first IV. Read a full chunk, and decrypt. Output the result as the first chunk of plaintext. Repeat.
This runs all the data through an authenticated cipher and verifies the authenticator before releasing the plaintext, but it does not verify the whole ciphertext before releasing some plaintext. Is this problematic, or is it generally considered safe? Is it safe in some circumstances, depending on your particular problem? Or does it invariably introduce serious flaws?
I realize that this is well into rolling-your-own-crypto territory, and do not plan to implement this myself. That said, what's the verdict on the approach? Are there alternative solutions to the problem? Is there a general approach that one can use to safely encrypt extremely large datasets with authenticated modes, or are any solutions still highly dependent on the exact problem being solved?
Update: Hoang, Reyhanitabar, Rogaway, and Vizár published a paper which defines the "STREAM" protocol that addresses this problem.