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

[Bernd Eckenfels]

Hello Matthew, List,

Am Thu, 6 Mar 2014 15:44:27 -0800
schrieb Matthew Hall <mhall at mhcomputing.net>:

> On Thu, Mar 06, 2014 at 10:01:57PM +0100, Bernd Eckenfels wrote:
> > My thinking was, that the "streamed" mode is usefull, but the
> > "secure" mode is also usefull. At least for BC I would recommend to
> > have two different cipher specs. A /GCM/ and a /GCMSTREAM/ mode.
> > The later one would not be enabled in FIPS mode. (Ideally BC uses
> > the same secure semantics with the JCE compatible spec).
> 
> Then you get very poor performance, with double-buffering, when the
> product is put into the FIPS mode.

Indeed, the "closed box" mode of the JCE Cipher where no
unauthenticated bytes are released has worse performance (large
footprint, no parallel stream processing), but there is a reason to do
it this way (like Florian, Valerie and Xuelei pointed out).

That is, why I want to keep the non-compliant mode of BC (especially
as it does not sound like Oracle/OpenJDK want to ship it). For BC
it would be wise to actually use a cipher identifier which is different
from the JCE one if the semantic is different (some argue better, some
argue worse).

If I know my steps which deal with the stream are safe (for example I
write the result to a temp file which gets deleted if close fails
verification) I can request the "unsafe" mode. If I implement something
like a "telnet" application I better make sure commands are not
executed before the trailer is verified (and therefore I use the normal
Cipher spec with the internal buffering of JDK8 provider). In those
situations the segments are typically small (think JSSE/TLS).

A small general comment: GCM is so hyped, and in other crypto system
implementations it really looks like a very good choice. But in the
Java world the missing native support (with resulting poor performance)
and this issue about compliance makes it a very bad choice. And I think
this also applies to ciphers.

IMHO a JEP to improve this situation is very much needed.

Gruss
Bernd