That's why limited block sizes are very nice, but CMS does not have a
maximum content size. The intent is for the overall hardware/software
solution to only reveal plaintext after it is
authenticated. However, I recognize a completely generic option
with no limitations is desired.
Both AES-CCM and AES-GCM have requirements that require the integrity
check to be performed before the plaintext is released.
Russ
At 01:02 AM 4/22/2007, Jim Schaad wrote:
As the document is currently written, it is basically impossible to do
streaming on a decode operation due to the following statement.
The recipient MUST verify the integrity of the received content
before releasing any information, especially the plaintext of the
content. If the integrity verification fails, the receiver MUST
destroy all of the plaintext of the content.
My first reading of this assumed that the low-level decryption routine
should be the one to take care of this statement. But the real question is
what is meant by "recipient".
If one makes the statement that the low level decryption code is responsible
for this, then making a hardware device to do the decryption becomes
difficult unless it sets limits on the length of the data that can be
decrypted. (The hardware would be required to buffer the contents on the
chip until it had finished doing the validation operation.)
If one makes the statement that the CMS code is responsible for this, code
could not be said to be compliant to RFC 3610 since it has a similar
statement in that document.
I have to say that if I were to implement this code I would be very tempted
to go ahead and do the decryption, stream the data out and return an error
code of validation failed much as is currently done for the current
EncryptedData and EnvelopedData structures.
Why should this document handle this differently that a padding failure for
those structures? I propose removing that restriction.
Jim