CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible

[Philipp Heckel]

Although Tim and Matthew already mentioned the main points, I'd like to
voice my concerns as well -- in particular because I think that this is
*not* a philosophical argument: Security must always be more important than
the supposedly correct semantics of a class or method.

If you tried the same test with SunJCE provider, you will find that none of
> the decrypted data is returned to the caller when the tag doesn't match. If
> the providers weren't modified to not returning any of the decrypted data
> AFTER the tag is verified, the root cause is not fixed and you can simply
> use Cipher to get hold of the decrypted data instead.
>

The whole purpose of Input/OutputStreams is to be able to avoid large
buffers and/or temporary files of any sort. For modes in which the tag is
appended to the ciphertext (including GCM), buffering all the data is
simply unacceptable, since if would make processing of large files simply
impossible.

Using the Cipher class directly is not an option either, because many
applications nest streams into one another. Chaining gzip+encryption is not
uncommon. If you process large amount of data, again, manually
unpacking/packing is not feasible.


> Thus, CipherInputStream class ignores AEADBadTagException isn't really the
> problem here, as the some of the decrypted data may have been returned to
> the caller before the tag is verified. Whether AEADBadTagException is
> ignored or not doesn't matter here.
>

Adding to what Matthew said: I think it does matter. Security-related
exceptions should never be hidden from the developer! Adding an
InvalidCipherTextIOException (like in BC) would not do any harm to existing
code and the API, since these kind of exceptions must be handled anyway.

Asked differently: Is there a particular reason why BadPaddingException and
IllegalBlockSizeException are ignored? Are there known issues that would
arise if they weren't ignored?

Best,
Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140304/9912fcbf/attachment.htm>