Re: [openpgp] [Cfrg] streamable AEAD construct for stored data?

[Bryan Ford <[e-mail]>]

P.S. Wherever ‘reputable’ appears in the message below that should have said ‘repudiable’.  Thanks Apple for spelling auto-corrections that completely obliterate the technical meaning of sentences… :(

On Feb 23, 2016, at 12:36 PM, Bryan Ford <[e-mail]> wrote:
> On Feb 10, 2016, at 1:52 PM, Nils Durner <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi,
>> 
>>> To be clear, there are two separate use-cases, each of which make
>>> sense without the other and require different technical solutions (but
>>> could also make sense together):
>>> 
>>> 1. Streaming-mode integrity protection:
>>> 
>>> [...]
>>> 
>>> To achieve goal #1 properly, it appears that what we need is not only
>>> a MAC per chunk but a signature per chunk.
>> 
>> Different ideas:
>> 
>> 1. asymmetrically encrypt and sign the MAC key, make this a new packet
>>   type to be prepended to the symmetrically encrypted data
> 
> By this, do you mean just write one asymmetrically encrypted-and-signed MAC key at the beginning of the stream, followed by a bunch of records that are only MAC-authenticated with that symmetric key?  
> 
> This would appear insecure to me, at least in the case the stream is encrypted to two or more recipients.  Say Alice signs-and-encrypts a stream to Bob and Charlie.  Bob takes Alice’s encrypted-and-signed MAC key record, then uses the same MAC key to construct a completely different stream of actual content (all of whose MAC records verify just fine) and sends it to Charlie, claiming that it’s from Alice.
> 
> Maybe this is only a problem in the two-or-more-receivers case, but even if so it makes me nervous.  If PGP had a reputable, non-signing sender-authentication mode for 2-party communication only, then it might make sense for an asymmetric “repudiable authentication record” to be followed by a stream of MAC-authenticated records. But that seems like a fairly different protocol (or at least a fairly different mode).
> 
>> 2. derive the MAC key from the symmetric encryption key, sign it (but
>>   do not store it) and make this a new packet type to be prepended
>>   (thus saving the asymmetric encryption from #1)
>> 3. use an authenticating sym cipher mode with intermediate
>>   authentication tags, with the symmetric key asymmetrically signed
>>   (like #2)
> 
> Assuming I’m correctly understanding that in cases #2 and #3 also just have one asymmetric record at the beginning of the stream, it seems like the same considerations apply as with #1.  Perhaps OK for 2-party repudiable authentication, but not if we need to retain the signed-message semantics that PGP currently provides especially in the multiple-receiver case.
> 
> Cheers
> Bryan