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

[Phillip Hallam-Baker]

On Thu, Oct 3, 2013 at 5:17 AM, ianG <iang at iang.org> wrote:

> On 2/10/13 17:46 PM, John Kelsey wrote:
>
>> Has anyone tried to systematically look at what has led to previous
>> crypto failures?
>>
>
> This has been a favourite topic of mine, ever since I discovered that the
> entire foundation of SSL was built on theory, never confirmed in practice.
>  But my views are informal, never published nor systematic. Here's a
> history I started for risk management of CAs, informally:
>

I don't understand what you mean there. The actual history of SSL was that
SSL 1.0 was so bad that Alan Schiffman and myself broke it in ten minutes
when Marc Andressen presented it at the MIT meeting.

SSL 2.0 was a little better but none of the people who worked on it had any
formal background in security. During the design process Netscape finally
got a clue and hired some real security specialists but one of Andresen's
hiring criteria was not to hire anyone from CERN who might suggest that the
Web had been invented by Tim Berners-Lee rather than himself so it took
them a lot longer than it needed to.

During that time I told them about their random number generator design
being barfed and they told me they would fix it but they didn't.

SSL 3.0 was designed by Paul Kocher as we all know and he did a pretty good
job. But they only gave him two weeks to work on it.

I don't think Paul's design was very theoretical and Netscape didn't give
him anywhere near enough time to do a full formal analysis of the protocol,
even were that possible with the tools available at the time.


It is far better to select a target such as 128 bit security, and then
> design each component to meet this target.  If you want "overdesign" then
> up the target to 160 bits, etc.  And make all the components achieve this.
>

I don't like that approach to hash function design.

Yes, I know that the strength of a 256 bit hash against a birthday attack
is 2^128 but that is irrelevant to me as a protocol designer as there are
almost no circumstances where a birthday attack results in a major
compromise of my system.

Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had no
impact on the security of certificates issued using MD5 until the attack
was dramatically improved and the second pre-image attack became feasible.

So I would rather that SHA3-256 provide a full 2^256 computational work
factor against pre-image attacks even if there is a birthday vulnerability.

> (3)  Don't accept anything without a proof reducing the security of the
>> whole thing down to something overdesigned in the sense of (1) or (2).
>>
>
>
> Proofs are ... good for cryptographers :)  As I'm not, I can't comment
> further (nor do I design to them).


Proofs are good for getting tenure. They produce papers that are very
citable.

-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131004/9af78562/attachment.html>