[147589] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (Bill Frantz)
Thu Oct 10 15:16:16 2013
X-Original-To: cryptography@metzdowd.com
Date: Wed, 9 Oct 2013 22:41:17 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Watson Ladd <watsonbladd@gmail.com>
In-Reply-To: <CACsn0cnNDddVVjDZzYtuVci=GfLryDG90bipiNtJ=9Pndj6j=Q@mail.gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 10/9/13 at 7:12 PM, watsonbladd@gmail.com (Watson Ladd) wrote:
>On Tue, Oct 8, 2013 at 1:46 PM, Bill Frantz <frantz@pwpconsult.com> wrote:
>>... 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.
When I developed the VatTP crypto protocol for the E language
<www.erights.org> about 15 years ago, key sizes of 1024 bits
were high security. Now they are seriously questioned. 3DES was
state of the art. No widely distributed protocols used
Feige-Fiat-Shamir or Schnorr signatures. Do any now? I stand by
my statement.
>>
>>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.
... long post of problems with TLS, most of which are valid
criticisms deleted as not addressing the above questions.
>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.
I agree with this general direction, but I still don't have the
warm fuzzies that good answers to the above questions might
give. I have seen too many projects to "do it right" that didn't
pull it off.
See also my response to John Kelsey.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | Privacy is dead, get over | Periwinkle
(408)356-8506 | it. | 16345
Englewood Ave
www.pwpconsult.com | - Scott McNealy | Los Gatos,
CA 95032
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
