Re: [openpgp] On Streaming and Chunking

[ianG <[e-mail]>]

On 24/03/2015 12:25 pm, Tom Ritter wrote:
> 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.



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.