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

Watson Ladd watsonbladd at gmail.com
Wed Oct 9 22:12:37 EDT 2013


On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>
> On 10/8/13 at 7:38 AM, leichter at lrw.com (Jerry Leichter) wrote:
>
>> On Oct 8, 2013, at 1:11 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>
>
>>> We seriously need to consider what the design lifespan of our crypto suites is in real life. That data should be communicated to hardware and software designers so they know what kind of update schedule needs to be supported. Users of the resulting systems need to know that the crypto standards have a limited life so they can include update in their installation planning.
>
>
>> This would make a great April Fool's RFC, to go along with the classic "evil bit".  :-(
>
>
> I think the situation is much more serious than this comment makes it appear. As professionals, we have an obligation to share our knowledge of the limits of our technology with the people who are depending on it. We know that all crypto standards which are 15 years old or older are obsolete, not recommended for current use, or outright dangerous. We don't know of any way to avoid this problem in the future.

15 years ago is 1997. Diffie-Hellman is much, much older and still
works. Kerberos is of similar vintage. Feige-Fiat-Shamir is from 1988,
Schnorr signature 1989.
>
> I think the burden of proof is on the people who suggest that we only have to do it right the next time and things will be perfect. These proofs should address:
>
>     New applications of old attacks.
>     The fact that new attacks continue to be discovered.
>     The existence of powerful actors subverting standards.
>     The lack of a "did right" example to point to.
As one of the "Do it right the first time" people I'm going to argue
that the experience with TLS shows that extensibility doesn't work.

TLS was designed to support multiple ciphersuites. Unfortunately this
opened the door to downgrade attacks, and transitioning to protocol
versions that wouldn't do this was nontrivial. The ciphersuites
included all shared certain misfeatures, leading to the current
situation.

TLS is difficult to model: the use of key confirmation makes standard
security notions not applicable. The fact that every cipher suite is
indicated separately, rather than using generic composition makes
configuration painful.

In addition bugs in widely deployed TLS accelerators mean that the
claimed upgradability doesn't actually exist. Implementations can work
without supporting very necessary features. Had the designers of TLS
used a three-pass Diffie-Hellman protocol with encrypt-then-mac,
rather than the morass they came up with, we wouldn't be in this
situation today. TLS was not exploring new ground: it was well hoed
turf intellectually, and they still screwed it up.

Any standard is only an approximation to what is actually implemented.
Features that aren't used are likely to be skipped or implemented
incorrectly.

Protocols involving crypto need to be so damn simple that if it
connects correctly, the chance of a bug is vanishingly small. If we
make a simple protocol, with automated analysis of its security, the
only danger is a primitive failing, in which case we are in trouble
anyway.
>
>
>> There are embedded systems that are impractical to update and have expected lifetimes measured in decades...
>>
>> Many perfectly good PC's will stay on XP forever because even if there was the will and staff to upgrade, recent versions of Windows won't run on their hardware.
>> ...
>>
>> I'm afraid the reality is that we have to design for a world in which some devices will be running very old versions of code, speaking only very old versions of protocols, pretty much forever.  In such a world, newer devices either need to shield their older brethren from the sad realities or relegate them to low-risk activities by refusing to engage in high-risk transactions with them.  It's by no means clear how one would do this, but there really aren't any other realistic alternatives.



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin


More information about the cryptography mailing list