Hello Matthew, List, Am Thu, 6 Mar 2014 15:44:27 -0800 schrieb Matthew Hall <mh...@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
