Subject: [Cfrg] Halon's Razor -> Re: NSA sabotaging crypto standards

From: Paul Lambert <[email-masked]>
Date: Fri, 7 Feb 2014 11:54:30 -0800

Changing the subject line since we are moving beyond the NSA conspiracy
theories.  The increased interest in security is a great benefit Š but
much of 
 
    "Never attribute to malice that which is adequately explained by
stupidity"
>>
>> I believe you are oversimplifying things. Indeed Rogaway suggested
>> encrypt-then-MAC, but other cryptographers were suggesting
>> MAC-then-Encrypt (authenticate what is meant not what is sent). There
>> was also no attack known for MAC-then-encrypt.
>
>Show me one cryptographer who recommended MAC-then-Encrypt.
>Also, absence of known attacks is not the same as absence of attacks.
>Encrypt-then-MAC was the conservative choice.
SIV is MAC then encrypt Š in it¹s own unusual manner.

Conservative from the view of simplicity of proof does not invalidate
other criteria. For example, Rivest¹s Tweakable Cipher¹s offers potential
for breaking away from conservative conventional wisdom.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 7 Feb 2014 12:16:22 -0800

Premature click-itis on prior post - sorry, please ignore …….

Changing the subject line since we are moving beyond the NSA conspiracy
theories.  The increased interest in security is a great benefit  but
much of our problems I fear are of our own creation:

Stupidity”    :-(

Improvements come not from accusations of past work, but a work plan to
look at new activities and better criteria.

Concrete suggestions:
 - identification and documentation of vulnerabilities and possible
“mistakes" 
 - identification and documentation of selection criteria
    - very interesting for ECC
      e.g. Benefits or issues of a = -3, p = pseudo mersenne,
      impact of zero value points and DPA
 - protocol review and refresh of guidelines and/or protocols
   - e.g. IPsec has a guideline I know needs changing …
 - re-examination of privacy in protocol designs
   - addresses, names and long term identifiers are the norm
     now … changes are possible

>Encrypt-then-MAC was the conservative choice.

SIV is MAC then encrypt in it¹s own unusual manner.  Conservative from the
view of simplicity of proof does not invalidate other criteria. For
example, Rivest¹s Tweakable Cipher¹s offers potential for breaking away
from conservative conventional block cipher wisdom. There are pseudo
homomorphic applications where it’s more appropriate to MAC-then-encrypt.
There continues to be a gulf between ‘applied crypto’ and 'academic
crypto’.  Adamant mandates of abstract guidelines will not build consensus
or good products.  Progress can be made by more rapid academic analysis of
‘real protocols’, and more rapid translation of academic work into useable
designs.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 7 Feb 2014 13:54:47 -0800

Tom,

Thank you for your shameless plug... it's very interesting work.  Also, my apologies on  my imprecise statement about SIV.  SIV is very interesting because it is NOT the conventional conservative model - it's clearly not encrypt-then-MAC.   It is an excellent example of out-of-the-conventional-box thinking that would be eliminated if we create arbitrary guidelines for algorithm structure.  

Do send a pointer to the list when it's posted.

Regards,

Paul

]-----Original Message-----
]From: Tom Shrimpton [mailto:[email-masked]]
]Sent: Friday, February 07, 2014 12:24 PM
]To: Paul Lambert
]Cc: [email-masked]; Watson Ladd; Nikos Mavrogiannopoulos
]Subject: Re: [Cfrg] Halon's Razor -> Re: NSA sabotaging crypto standards
]
]
]
]On Fri Feb 7 11:54:30 2014, Paul Lambert wrote:
]>> Show me one cryptographer who recommended MAC-then-Encrypt.
]>> Also, absence of known attacks is not the same as absence of attacks.
]>> Encrypt-then-MAC was the conservative choice.
]>
]> SIV is MAC then encrypt Š in it¹s own unusual manner.
]As one of the designers of SIV, I have to object to saying that SIV is
]MAC-then-encrypt, even if you soften the claim with "in it's own unusual
]manner."  SIV doesn't fit into any of the traditional generic
]composition categories -- MAC-then-encrypt, encrypt-then-MAC, encrypt-
]and-MAC -- for a number of reasons.
]
]For one thing, treating the PRF output as the IV (and the transmitted
]tag!) is quite different that treating it as part of the plaintext to be
]encrypted.
]
]For another, SIV mode neither starts with, nor yields the kind of
]cryptographic object that the Bellare-Namprempre results address.
](I'm pointing to the (excellent) [BN] paper because it has significantly
]shaped the way our community thinks about building AE schemes via MtE,
]EtM and
]E&M.)
][BN] is about producing *probabilistic* AE schemes from *probabilistic*
]encryption, and a MAC.  But SIV is a *deterministic*, nonce-based AE
]scheme, built from an underlying *deterministic*, IV-based encryption
]scheme, and a PRF.
]
]This is something that Phil Rogaway, Chanathip Namprempre and I have
]been thinking about a lot lately -- what is the GC story when one starts
]from nonce-based or IV-based encryption, and a PRF, and wants to produce
]a nonce-based AEAD scheme?
]At Eurocrypt 2014, we'll present a paper that explores this question in
]detail.
](You can expect the full version to appear on the IACR eprint server in
]the next week or so.)
]
]Sorry if that seemed like a shameless plug, but it did seem appropriate
]to mention the upcoming paper as part of this response.
]
]Cheers,
]-Tom Shrimpton

---

From: David McGrew <[email-masked]>
Date: Fri, 07 Feb 2014 17:07:22 -0500

Quick note to the list: Tom's original email, copied below, hasn't hit 
the list yet, I think because he sent it from a non-subscribed email 
account.   I think that Kevin added this other account as a member, but 
this won't re-send the message.   So read Tom's original message at the 
bottom first, then Paul's response above it :-)

David

On 02/07/2014 04:54 PM, Paul Lambert wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Feb 2014 17:11:27 -0800

> look at new activities and better criteria.

Well, one good criterion would be requiring documentation of
assumptions and the security actually provided by a protocol. The
reason we should ask for this is that it would have stopped attacks in
the past. That's why the history of TLS matters: it makes the case
that the past practices weren't good enough, and raises the question
of what practices would have stopped the problems that were
identified.

>       e.g. Benefits or issues of a = -3, p = pseudo mersenne,

So draft-ladd-safecurves will have this. I've been doing other things
for a while, and we also are still searching for the best point
format, but hopefully I will be able to discuss the whole landscape.

> ‘real protocols’, and more rapid translation of academic work into useable

The reason academic analysis of real protocols takes a while is many
real protocols have features that make analysis hard. Key confirmation
is a particular pain point, but so is having lots of slightly
different mechanisms, instead of one overall mechanism with some
options. I'll have to disagree with protocol papers not being usable
designs: you take the protocol, look what it requires, and pick one
for each thing it needs.

For example I'll take http://eprint.iacr.org/2013/171.pdf, mostly at
random. There is a table in there (figure 5) describing a signature
scheme in fairly standard notation. There are some nonstandard bits,
but mostly definitions. It looks to me like translating it into an RFC
would take a few choices of primitive, but not much additional work.
What else would you desire to make it more implementable?
> Paul
Sincerely.
Watson Ladd