Neal,
"Neal H. Walfield" <neal(_at_)walfield(_dot_)org> writes:
...really? All this is just to save a few cpu cycles in the rare
cases of data
corruption that should have been handled by other layers
(filesystem / transport
layer) in the first place? Why even bother?
No, it is more than that. Imagine using OpenPGP to encrypt a full
filesystem to tape backup. You necessarily want to be able to chunk
that as you are saving (and restoring).
I don't think Vincent is disputing the validity of Werner's use case
per se. I think he is saying the marginal utility of that is tiny
(it's "just a performance improvement") relative to ciphertext
integrity (a security property).
IMHO it is a bit of both. Again, looking at this historically (having
written the original streaming code back in ~1995), the idea was to
provide early-notification of cryptographic failure without having to
buffer the whole complete message. Granted, this was written before
AEAD techniques came into the public eye, but I don't think I would have
done it much differently at the time.
There were at the time systems with limited RAM and/or temp space, but
we still wanted to be able to encrypt & sign LARGE data sets. Again,
think of a 'tar -czf - / | pgp ... | <network or tape>' as the model we
were using at the time.
If you are on tape, you CAN get "transmission" errors. Think: Bit Rot.
It's a real thing. Spinning rust can also have failures, but it's a bit
less common. Even RAM can have bit errors -- this is why ECC (error
correction, not elliptic curve) RAM is used in servers!
Protecting against transmission error, bit rot, etc is just common
sense!
But the ability to do this in a space that can't "hold" the full data
set is exactly why we have streaming capability.
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp