Subject: [saag] MAC first then encrypt or encrypt then MAC.

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jun 2012 13:26:33 -0400

OK, so I think I know the answer to this one, but every single time I
submit a spec doing it one way, someone will always tell me that the
other is the way to go. And very rarely will anyone give a reason
other than 'that is how to do it'.

And no, 'just use TLS or DTLS' is not an option in this particular protocol.

I have found http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
but while the paper is very good and worth reading, it is focused on
public key issues. I am wondering if some of the 'you must sign first'
advice is coming from people translating advice specific to public key
back to symmetric key protocols.

What I am planning to do is:

1) Starting from a master shared secret km produce distinct keys ks,
ke for signing and encryption respectively.

[e.g. ks = MAC ("sign", km), ke = MAC ("encrypt", km)]

2) Construct either

Encrypt-then-sign  Message = Encrypt (Payload, ke) + Authenticate
(Encrypt (Payload, ke), ks)

Sign-the-encrypt  Message = Encrypt (Payload + Authenticate (Payload, ks), ke)

[I am aware that certain communities would advise

  P2 = Encrypt (Payload + Authenticate (Payload, ks), ke)
  Message = Encrypt (P2+ Authenticate (P2, ks), ke)

But I don't have the room for it]

What I am really looking for here is not so much an argument as a
reference I can cite.

Looking at the current JSON signature etc spec it looks to me like
Encrypt-then-sign is expected.

This is to be used in:
http://www.ietf.org/id/draft-hallambaker-omnibroker-00.txt in case you
need context.

-- 
Website: http://hallambaker.com/

---

From: Tom Yu <[email-masked]>
Date: Wed, 27 Jun 2012 14:28:40 -0400

> back to symmetric key protocols.

Are you focusing on symmetric key use cases?

I think http://cseweb.ucsd.edu/~mihir/papers/oem.pdf and related work
might be what you want to look at.

What security properties are you looking for?  In the above paper,
only Encrypt-then-MAC using a strongly unforgeable MAC provides
IND-CTXT integrity and NM-CPA security; the other alternatives are
weaker.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 27 Jun 2012 14:47:51 -0500

> other than 'that is how to do it'.

Well how about sidestepping the debate and using an intrinsically 
authenticated encryption mode such as GCM, CCM, or EAX?

http://en.wikipedia.org/wiki/GCM_mode
http://en.wikipedia.org/wiki/CCM_mode
http://en.wikipedia.org/wiki/EAX_mode

Why:

* The encryption and message authentication are integrated rather than 
separate operations.

* There's less to go wrong.

* Often more efficient.

* GCM parallelizes.

* GCM is standardized by NIST and is NSA Suite B.

* GCM is referenced by RFC 4106 (GCM for IPsec ESP) and 5288 (AES GCM 
for TLS)

* Packaged and tested implementations are available in many crypto 
libraries.

* The modes I listed are believed patent-free.

Why not:

* GCM really needs a 128 bit or longer tag. But you were probably 
looking at a minimum of 160 bits for SHA-1 anyway.

* It's hard to choose among the options.

- Marsh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Jun 2012 16:02:27 -0400

On Wed, Jun 27, 2012 at 3:47 PM, Marsh Ray <[email-masked]> wrote:
> * GCM is referenced by RFC 4106 (GCM for IPsec ESP) and 5288 (AES GCM for
> TLS)
>
> * GCM really needs a 128 bit or longer tag. But you were probably looking at
> a minimum of 160 bits for SHA-1 anyway.
>

I think you are right. But I am not comfortable with doing more than
making support for something like GCM a requirement for the service
side at this point.

Selling the protocol is going to be hard enough without doing
trailblazing. I can make a very good case for requiring combi mode on
the server so that embedded devices can be supported. Requiring it on
the client side would be problematic given the need to implement in
various scripting languages,