[Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

[Bill Frantz]

On 10/9/13 at 7:18 PM, crypto.jmk at gmail.com (John Kelsey) wrote:

>We know how to address one part of this problem--choose only 
>algorithms whose design strength is large enough that there's 
>not some relatively close by time when the algorithms will need 
>to be swapped out.  That's not all that big a problem now--if 
>you use, say, AES256 and SHA512 and ECC over P521, then even in 
>the far future, your users need only fear cryptanalysis, not 
>Moore's Law.  Really, even with 128-bit security level 
>primitives, it will be a very long time until the brute-force 
>attacks are a concern.

We should try to characterize what "a very long time" is in 
years. :-)


>This is actually one thing we're kind-of on the road to doing 
>right in standards now--we're moving away from 
>barely-strong-enough crypto and toward crypto that's going to 
>be strong for a long time to come.

We had barely-strong-enough crypto because we couldn't afford 
the computation time for longer key sizes. I hope things are 
better now, although there may still be a problem for certain 
devices. Let's hope they are only needed in low security/low 
value applications.


>Protocol attacks are harder, because while we can choose a key 
>length, modulus size, or sponge capacity to support a known 
>security level, it's not so easy to make sure that a protocol 
>doesn't have some kind of attack in it.
>I think we've learned a lot about what can go wrong with 
>protocols, and we can design them to be more ironclad than in 
>the past, but we still can't guarantee we won't need to 
>upgrade.  But I think this is an area that would be interesting 
>to explore--what would need to happen in order to get more 
>ironclad protocols?  A couple random thoughts:

I fully agree that this is a valuable area to research.

>
>a.  Layering secure protocols on top of one another might 
>provide some redundancy, so that a flaw in one didn't undermine 
>the security of the whole system.

Defense in depth has been useful from longer ago than the 
Trojans and Greeks.


>b.  There are some principles we can apply that will make 
>protocols harder to attack, like encrypt-then-MAC (to eliminate 
>reaction attacks), nothing is allowed to need change its 
>execution path or timing based on the key or plaintext, every 
>message includes a sequence number and the hash of the previous 
>message, etc.  This won't eliminate protocol attacks, but will 
>make them less common.

I think that the attacks on MAC-then-encrypt and timing attacks 
were first described within the last 15 years. I think it is 
only normal paranoia to think there may be some more equally 
interesting discoveries in the future.


>c.  We could try to treat at least some kinds of protocols more 
>like crypto algorithms, and expect to have them widely vetted 
>before use.

Most definitely! Lots of eye. Formal proofs because they are a 
completely different way of looking at things. Simplicity. All 
will help.

>
>What else?
>...
>>Perhaps the shortest limit on the lifetime of an embedded 
>>system is the security protocol, and not the hardware. If so, 
>>how do we as society deal with this limit.
>
>What we really need is some way to enforce protocol upgrades 
>over time.  Ideally, there would be some notion that if you 
>support version X of the protocol, this meant that you would 
>not support any version lower than, say, X-2.  But I'm not sure 
>how practical that is.

This is the direction I'm pushing today. If you look at auto 
racing you will notice that the safety equipment commonly used 
before WW2 is no longer permitted. It is patently unsafe. We 
need to make the same judgements in high security/high risk applications.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |The nice thing about standards| Periwinkle
(408)356-8506      |is there are so many to choose| 16345 
Englewood Ave
www.pwpconsult.com |from.   - Andrew Tanenbaum    | Los Gatos, 
CA 95032