Re: [Cfrg] Task looming over the CFRG

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

> ….this argument might not be convincing, but I hope it at least sounds
> reasonable and worth further discussion.

Well, I asked not for an argument – but for a reason & explanation.  :-)
Your answer provided both, thank you!

> ……This is why people don’t use AES-192.  Some engineers are designing for
> performance- or memory-sensitive applications, or don’t like over-engineering,
> and they pick AES-128.  Others would rather be more conservative, and they pay
> the extra 40% to go to AES-256.  The halfway solution of AES-192 isn’t used,
> because it isn’t the optimum for anyone’s performance budget.

Interesting. So nobody ways "I want to be a little faster and cheaper than
AES-256, but I have to be more secure than AES-128"…? I'm surprised.

> So it makes sense that people commonly use AES-256 and sometimes use p384, but
> rarely p521 and never AES-192.  Going from AES-192 to AES-256 costs 20% on a
> function which is hardware-accelerated and probably not the bottleneck anyway.
> Going from p384 to p521 doubles an already expensive computation (and maybe
> also gets you sued for patent infringement, but hopefully we can avoid that
> this time around).

I understand your reasoning now. And I think you just gave a probable reason
why P521 wasn't used much so far. (Better to carry 15K-bit keys than being
sued for a 521-bit key :)

Again, thanks for explaining!


> On May 5, 2014, at 2:34 PM, Blumenthal, Uri - 0668 - MITLL <[e-mail]>
> wrote:
> 
>> IMHO, the logic/reason of matching security levels of the cryptographic
>> algorithms employed in a protocol suite is fairly obvious and does not need
>> an explicit justification. There might be a reason to have the
>> key-protecting/key-wrapping algorithm a bit (no pun intended! :) stronger
>> than the one that uses that key. I can't think of a reason to protect a key
>> with a weaker algorithm than the key-using one.
>> 
>> You observed that strength-matching was not done with RSA (considering the
>> key sizes involved, and where those keys may need to be stored and processed,
>> one possible reason for that mismatch pops up automatically :).
>> 
>> More surprisingly, matching was not done with ECC either. We don't have an
>> explanation for this design choice. Copying designs we don't understand (or
>> do we?) does not sound like a good recipe.
>> 
>> Let me ask you: could you explain why you want to mix algorithms of different
>> cryptographic strength? What benefit do you derive from including a stronger
>> algorithm in a chain made of weaker algorithms? How big would your
>> performance gain be?
>> --
>> Regards,
>> Uri               <[e-mail]>
>> 
>> 
>> On May 5, 2014, at 16:55 , Michael Hamburg <[e-mail]>
>>  wrote:
>> 
>>> Kevin,
>>> 
>>> Sorry to be ambiguous: the curve I designed has a 448-bit field and a
>>> 446-bit prime-order subgroup, so a parallel rho attack should cost just
>>> under 2^223 point operations on average.  So it sits between the 192 and
>>> 256-bit security levels.
>>> 
>>> I’m not particularly invested in getting this curve into TLS, but I’d like
>>> to know whether there’s a point in submitting it for this purpose, or if it
>>> will be rejected for having the “wrong security level".
>>> 
>>> Matching the nominal security level of the asymmetric part to that of the
>>> symmetric part sounds obvious on its face, but in fact it is not usually
>>> done above the 128-bit level.  For example, Suite B doesn’t specify a direct
>>> matching of nominal security levels: it specifies AES-256 with SHA-384 and
>>> ECDSA-NIST-p384 for TOP SECRET communications.  Likewise, almost nobody
>>> pairs AES-256 with the matching RSA-15k, and even AES-128 is usually paired
>>> with the nominally weaker RSA-2048.
>>> 
>>> This actually makes sense.  Nobody is going to do a 128-bit exhaust for many
>>> decades.  Not Google, not the NSA, not the KGB, nobody.  With today’s most
>>> efficient supercomputers, the heat output from 2^128 operations would be far
>>> more than enough to boil the oceans dry [1].  So we’re talking about
>>> defenses against sub-128-bit attacks, and defense in depth against
>>> hypothetical advances in cryptography, and quantum resistance for primitives
>>> that can resist at all.  Stronger curves, ciphers and hashes will stand or
>>> fall on their own, not all together as computer power surpasses their
>>> nominal security level.
>>> 
>>> Also, nobody uses AES-192.
>>> 
>>> So I don’t think it’s obvious that matching the AES security levels is a
>>> requirement.  If the RG thinks it is, or if there’s some obscure legal
>>> requirement that the levels match, then fine.  Just describe why.
>>> 
>>> Cheers,
>>> — Mike
>>> 
>>> [1] Lenstra, Kleinjung, Thomé.  “Universal security: from bits and mips to
>>> pools, lakes — and beyond”.  https://eprint.iacr.org/2013/635.pdf
>>> 
>>> On May 5, 2014, at 12:49 PM, Igoe, Kevin M. <[e-mail]> wrote:
>>> 
>>>> Mike:
>>>>  
>>>>   Being off by a few bits isn’t a show stopper. but 32-bits is probably too
>>>> much.  The security levels echo the AES security levels of AES-128, AES-192
>>>> and AES-256.  Using a 224 bit curve with AES-128 only provides roughly
>>>> 112-bits
>>>> of security versus the 128 bits ostensibly provided by AES-128.  I just
>>>> want to ensure
>>>> that a user who thinks they are getting 128 bits of security gets 128 bits
>>>> of 
>>>> security.
>>>>  
>>>>                               Kevin
>>>>  
>>>> From: Michael Hamburg [mailto:[e-mail]]
>>>> Sent: Monday, May 05, 2014 2:25 PM
>>>> To: Igoe, Kevin M.
>>>> Cc: [e-mail]
>>>> Subject: Re: [Cfrg] Task looming over the CFRG
>>>>  
>>>> Hi Kevin,
>>>>  
>>>> As the designer of an ECC system which is aimed at 224-ish-bit security,
>>>> I’m curious: is it a firm requirement that the curves be set at 128, 192
>>>> and 256 bits?  Or was there consensus in the meeting that the curves should
>>>> be set at these security levels?  Patrick Longa aimed his talk at these
>>>> security levels, but I don’t recall this being stated as a requirement.
>>>>  
>>>> Cheers,
>>>> — Mike
>>>>  
>>>>  
>>>> On May 5, 2014, at 10:58 AM, Igoe, Kevin M. <[e-mail]> wrote:
>>>> 
>>>> 
>>>> As most the folks who read this list have noticed, a virtual interim
>>>> meeting of the CFRG
>>>> was held on Tues 29 April to discuss the way forward for elliptic curve
>>>> cryptography
>>>> in the IETF.  This was driven by an earnest plea from the TLS WG for firm
>>>> guidance from 
>>>> the CGRG on the selection of elliptic curves for use in TLS.  They need an
>>>> answer before 
>>>> the Toronto IETF meeting in late July.  TLS needs curves for several levels
>>>> of security (128,
>>>> 192 and 256), suitable for use in both key agreement and in digital
>>>> signatures.
>>>>  
>>>> ·         The consensus of the attendees was that it would be best for TLS
>>>> to have a single
>>>> “mandatory to implement” curve for each of the three security levels.
>>>>  
>>>> ·         Though the attendees were reluctant to make a formal commitment,
>>>> there
>>>> was clearly a great deal of support for the Montgomery curve curve25519
>>>> (FYI, the 
>>>> 25519 refers to the fact that arithmetic is done modulo the prime 2**255 –
>>>> 19 ).
>>>>  
>>>> ·         curve25519 only fills one of the three required security levels.
>>>> We still need
>>>> curves of size near 384 bits and 512 bits.
>>>>  
>>>> ·         NIST curves: I doubt TLS will be willing to revisit the question
>>>> of elliptic curves once the
>>>> CFRG has made their recommendation.  Another option to consider is advising
>>>> TLS to
>>>> use of the NIST curves in the short term, buying time for the CFRG to do an
>>>> unrushed 
>>>> exploration of the alternatives, drawing academia and other standards
>>>> bodies into the
>>>> discussion.
>>>>  
>>>> P.S.  It has been suggested that the CFRG hold a session at the Crypto
>>>> conference in
>>>> Santa Barbara in an effort to draw in more participation from the academic
>>>> community.
>>>> No guarantees we can pull this off, but it is worth the attempt. Thoughts?
>>>> Volunteers?
>>>>  
>>>> P.P.S. We need to start lining up speakers for the CFRG session at IETF-90
>>>> (Toronto).
>>>>  
>>>>  
>>>> ----------------+--------------------------------------------------
>>>> Kevin M. Igoe   | "We can't solve problems by using the same kind
>>>> [e-mail]  | of thinking we used when we created them."
>>>>                 |              - Albert Einstein -
>>>> ----------------+--------------------------------------------------
>>>>  
>>>>  
>>>>  
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> [e-mail]
>>>> http://www.irtf.org/mailman/listinfo/cfrg
>>> 
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/cfrg
>> 
>