Subject: [openpgp] On Streaming and Chunking

From: Tom Ritter <[email-masked]>
Date: Tue, 24 Mar 2015 07:25:31 -0500

Adam's post on streaming API's has been posted before:
https://www.imperialviolet.org/2014/06/27/streamingencryption.html

The same problem is the root cause of the Java GCM CipherInputStream
issue: http://blog.philippheckel.com/2014/03/01/cipherinputstream-for-aead-modes-is-broken-in-jdk7-gcm/

But I haven't seen any discussion of Adam's point that one _can_
construct a format for chunking and authenticating the chunks (and
ordering thereof) to provide authenticated streaming. And that someone
has already done so:
https://github.com/kaepora/miniLock#4-file-encryption

I think support for a mode like this would be good to consider, and I
think if IPR allows it, a fully-specified design for it is a good
place to start.

-tom

---

From: ianG <[email-masked]>
Date: Thu, 26 Mar 2015 14:07:18 +0000

> think if IPR allows it, a fully-specified design for it is a good

Part of the problem here is that there are a few too many moving parts.

One moving part in particular is the interface design.  It has been an 
article of faith for a long time that the crypto libraries should 
deliver to the application a CIPHER metaphor, and that's good enough for 
any programmer.  And a MAC metaphor.  And a MODE metaphor.  Which has 
gradually morphed into a CIPHER/MODE/MAC metaphor.

Instead it would be better if the crypto library delivered a PROTOCOL 
metaphor.  For an example of this, look to djb's cryptobox.  It delivers 
a complete arrangement for doing authentication using private/public 
keypairs.  I do something similar, I call them Cryptors or Bees, to 
indicate they do "stuff" that isn't amenable to any easy boxing.

Part of the fight against this move up the stack is the 
'standardisation' argument, but this is only partially correct.  It is 
entirely possible to standardise around djb's example.  Just 
uncomfortable for some.

Now, with this in mind, why does this cause a problem?  Well, as there 
is more and more cruft added into the Java Cipher class, it is 
inevitable that they are going to get it wrong at some point.  Taking 
from the above links:

    Cipher c = Cipher.getInstance("AES/GCM/NoPadding", "BC");

That's just an open door for trouble, it's the cryptoplumbing equivalent 
of a goto.

iang

ps; I'm not entirely convinced I have the above argument fulsome and 
correct.  It's a sort of evolving critique against crypto libraries, 
there is something there/wrong, and I'm slowly trying to tease out what 
it is.