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

[Sean Turner <[e-mail]>]

On Dec 27, 2013, at 17:01, David McGrew <[e-mail]> wrote:

> Hi Watson,
> 
> thanks for your comments.
> 
> On 12/24/2013 09:45 AM, Watson Ladd wrote:
>> 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.
> 
> 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.

Note that Kevin (with some help from Henrik) also set up a wiki:

http://trac.tools.ietf.org/group/irtf/trac/wiki/cfrg

It’s unpopulated at this point but anybody with a datatracker login (http://tools.ietf.org/newlogin) can edit it.

>> 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.
> 
> Agreed.

This seems like an excellent suggestion.  Interestingly enough when I was working on [0]-[4] with Lily a couple of the authors of the “attack” papers actually provided input so it would be great as people found/learned weakness they could update the list.  There’s already some of this out there on wikipedia.

I was actually hoping that we could use this draft/wiki as a way to encourage/shame folks in to supporting algorithm agility. But maybe that’s just me.

The thing though is no matter what we write down isn’t necessarily going to affect implementations.  I’d like to think that folks read them and then implement them but then there’s the real world full of implementation/upgrade schedules/cost etc.  But, I do think it’s worth at least getting on record of saying hey you that thing you’ve been doing for years we said years ago was not the the thing to be doing.

>> 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.
> 
> 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.

I’m not against design diversity (and I’m all for the discussion) but I guess I’m skeptical whether the criteria for selection will end up being different.  Few users pick algorithms they just get the ones implemented by whatever application (and I use that term loosely) they’re using and all they might know is that it’s considered “secure”.

>> 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.
> 
> That's an interesting challenge, and I have a proposal that I would like to make in this space.

I’m all about having the CFRG publish all kinds of documents related to cryptographic algorithms, but what this really comes down to is people writing those documents.  And the best thing here … there’s *nothing, nada, zilch, null, zéro, صفر, 零* stopping you from writing a draft on your favorite topic.

Seriously, if there’s anybody out there wondering how to contribute I will (or will find somebody to) help you navigate the process.

>> 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.
> 
> 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
> 

spt

[0] https://datatracker.ietf.org/doc/rfc6149/
[1] https://datatracker.ietf.org/doc/rfc6150/
[2] https://datatracker.ietf.org/doc/rfc6151/
[3] https://datatracker.ietf.org/doc/rfc6194/

>