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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp