Subject: [Cfrg] Comments on draft-mcgrew-standby-cipher-00/draft-irtf-cfrg-cipher-catalog-01

From: Watson Ladd <[email-masked]>
Date: Tue, 24 Dec 2013 09:45:52 -0500

Dear all,
David McGrew invited us to comment on these, and since they cover
similar ground I decided to take them both on at once.

The basic problem I see is one is a bibliography and the other is a
wishlist. I don't see them
as being useful to someone simply asking the questions "what should I
use?" and "how do I
ensure algorithm agility is useful?"

The cipher catalog needs to be kept up to date, and I don't really see
a reasonable mechanism for doing it in the form of an internet draft.
Something along the lines of the X lounge, where X is hash function,
pairing, block cipher, stream cipher, or ala EFD/Safecurves is
probably a better format. It also needs a summary of the best attacks:
I should see something like "chosen ciphertext 2^36 texts, 2^192.5
time" for all ciphers, not just some. It's also missing Salsa20 and
ChaCha20.

The standby cipher document is a wishlist. It lists desirable
features, but doesn't propose any block cipher that can meet those
requirements. Instead it hopes that someone, somewhere will propose a
cipher that works.

That said these are the sorts of documents we need to see more of. I
personally think we should make a document "How to use a short shared
secret to protect a stream of messages", so as not to expose WGs to
the complexity of modes of operation.
It's a very solved problem, lots of protocols try to solve it, and
many get it wrong. Before I write a draft I'ld like to see if anyone
has strong objections to AES-GCM with counters for
nonces/XSalsa20+Poly1305 with counters for nonces. This is what is
deployed in Chrome, and both are fast on commodity chips and have
explicit security guarantees.

If possible both should be options: AES-GCM for speed on new Intel
chips, XSalsa20+Poly1305 on all other 32-bit chips with side channel
security.

Sincerely,
Watson

---

From: David McGrew <[email-masked]>
Date: Fri, 27 Dec 2013 17:01:45 -0500

Hi Watson,

thanks for your comments.

On 12/24/2013 09:45 AM, Watson Ladd wrote:
> probably a better format.

Agreed.  There is preliminary work in the direction of a 'cipher lounge' 
at http://www.mindspring.com/~dmcgrew/ic/about.html  .   It is important 
to also have an RFC on this topic, even if it won't be completely 
up-to-date, because RFCs are the official record, so to speak.

> It also needs a summary of the best attacks:

Agreed.

> requirements. Instead it hopes that someone, somewhere will propose a

There is less agreement on the standby cipher document.   Perhaps you 
and I agree, since you see the list of desirable features as the 
important thing, and I do to.   (Of course, CFRG has not yet agreed on 
the criteria.)   There was a comment from a gentleman whose name escapes 
me right now who strenuously disagreed with the requirement of "design 
diversity".   He felt that the "standby" idea is wrong, and that the 
next cipher design should just be chosen on its merits, regardless of 
any design similarity to or independence from AES.   I would love to see 
more discussion on this point.

> the complexity of modes of operation.

That's an interesting challenge, and I have a proposal that I would like 
to make in this space.

> chips, XSalsa20+Poly1305 on all other 32-bit chips with side channel

A question: would this draft build on top of RFC 5116 and 
draft-mcgrew-iv-gen-03, or would it do something different?   (I'd like 
to see an AEAD algorithm based on salsa20 with poly1305, assuming that 
the consensus is that salsa20 is OK, and does not need to be swapped 
with chacha.)

My opinion: whatever application is making use of the cryptography 
should *not* have to deal with nonces.   Even if the algorithm requires 
distinct nonces, if we have a single encrypter per key, then it is 
trivial to have nonces generated inside of the crypto implementation, 
and have all of that complexity hidden from the calling application.   
Of course, there are also algorithms that are robust against nonce 
misuse, and those which do not use nonces at all, and those are the 
algorithms that deserve attention from the research community and the RG 
in my opinion.

David

>
> Sincerely,
> Watson
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Robert Ransom <[email-masked]>
Date: Fri, 27 Dec 2013 18:15:46 -0800

On 12/27/13, David McGrew <[email-masked]> wrote:

> (I'd like

ChaCha is faster than Salsa20, and also provides security with fewer
rounds.  There is no technical reason to prefer Salsa20 over ChaCha.

> and have all of that complexity hidden from the calling application.

Tarsnap had a single process encrypting messages with each symmetric
key.  Its author accidentally removed the code to increment the nonce
between messages, and because its protocol sent the nonce explicitly
with each message, no one noticed the flaw for over a year (see
<http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html>).

Never reuse a symmetric encryption *key* for more than one
non-interactive message or one interactive connection, and never send
an explicit nonce with any message -- use a fixed nonce for
non-interactive protocols, and use the message number as the nonce in
an interactive connection protocol.

Robert Ransom