Re: [openpgp] On Streaming and Chunking

ianG <> Thu, 26 March 2015 14:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 574DE1A88C8 for <>; Thu, 26 Mar 2015 07:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y1CZ40qXrdX0 for <>; Thu, 26 Mar 2015 07:07:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56BBE1A8700 for <>; Thu, 26 Mar 2015 07:07:21 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id F2A736D787; Thu, 26 Mar 2015 10:07:19 -0400 (EDT)
Message-ID: <>
Date: Thu, 26 Mar 2015 14:07:18 +0000
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [openpgp] On Streaming and Chunking
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Mar 2015 14:07:23 -0000

On 24/03/2015 12:25 pm, Tom Ritter wrote:
> Adam's post on streaming API's has been posted before:
> The same problem is the root cause of the Java GCM CipherInputStream
> issue:
> 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:
> 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.


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.