Re: Composing signing and encryption

On 4 May 2016 at 00:47, Erik Nygren <erik@nygren.org> wrote:
> 1) In the 1:1 scenario with oob key exchange, it seems like encryption with
> AEAD gives you everything you need for privacy and integrity?

Pretty much, assuming that you do the oob key exchange properly.  Much
of the complication in WebPush (for example) arises from that.

> 2) In the 1:many scenario with oob key exchange (eg, file sharing and blind
> caching) it seems like we always need something to provide integrity
> (ideally streaming content integrity such as MICE, or at least a full
> content MAC such as in SRI but that limits applicability), plus encryption
> (which can be AEAD but we may not get much from it?).  Presumably if the
> content is also encrypted we should be doing encrypt-then-MAC?  My big
> concern here is that since the "many" has the encryption key (even with
> asymmetric key exchange) then anyone recipient or cache can trivially alter
> the data.

That's the reason that you distribute a hash.  You can't modify
content if everyone expects a particular hash.

> I haven't thought as much about the asymmetric key-exchange scenarios or how
> necessary they are for the complexity they add?

For encryption, these are the bulk of the complexity, yes.  But I'd be
against removing it without stronger reasons.  Using symmetric keys
changes the dynamics of WebPush and will require re-evaluation of the
system: for instance, it means that anyone able to send a message is
also able to read any message.

> So while it may make sense to drop the asymmetric key-exchange, I feel the
> subtleties of encrypted-content-encoding for the 1:many scenario resulting
> in a lack of integrity protections is going to be dangerous and lost on
> folks.  As such, I'd much prefer to see something like MICE folded into
> encrypted-content-encoding or specified alongside it with clear
> cross-references on how to safely compose them  (encrypt-then-MAC, or
> just-MAC with supported cipher+mac combos?)

I think that the parallel with block cipher modes is a misleading one.
Hash-based integrity and encryption can be applied in any order.

The problem that we're looking to avoid here is the one that arises
where identity is involved.  That is, there are problems when
endpoints make assumptions about identity based on the keys that are
used in messages, or assumptions about the binding of identities to
other things.

A simple integrity check avoids that morass.  It's only when you have
a signature that it gets complicated.

Received on Wednesday, 4 May 2016 02:04:13 UTC