Bill Sommerfeld's Weblog

Still Under Construction. Watch for falling objects


20040825 Wednesday August 25, 2004

Features vs Quality I just read John Clingan's post on Features over Quality.

At a previous employer (left nameless to protect the guilty..), I had realized that I wanted out and gave notice just as it was announced that the company was being taken over by a competitor. During the customary two week notice period, some folks from the new management came through, and, at an all-hands meeting for the site, emphasized that feature count, not quality, was what caused "us" to make sales.. and that we therefore shouldn't put any effort into fixing customer-experienced bugs lest it get in the way of adding new features to the product.

Gah. Were I not already on the way out, I would have given notice shortly after the meeting. Instead, I quietly got up and left the room in the middle of the meeting.

(2004-08-25 13:24:39.0) Permalink

20040818 Wednesday August 18, 2004

Getting the details right.. A C-Net story today reports:

The excitement began Thursday with an announcement that French computer scientist Antoine Joux had uncovered a flaw in a popular algorithm called MD5, often used with digital signatures. Then four Chinese researchers released a paper that reported a way to circumvent a second algorithm, SHA-0. err, um. Joux announced a SHA-0 collision, while the chinese found the MD5 collision.

The attack doesn't really "circumvent" SHA-0, and it's not like anyone actually uses the original SHA .. NIST announced that it was flawed in some unspecified way and replaced by SHA-1 which added a rotate to the message schedule for improved mixing.

The report then goes on to mention the use of MD5 by the Solaris Fingerprint Database -- a list of MD5 hashes of officially released solaris binaries -- without clarifying that the attacks on MD5 announced yesterday are not directly relevant to the use of MD5 by the SFPDB.

The research may well be a stepping stone to a future preimage attack on MD5, but it does not put it at risk today; the research likely also will point towards newer hash functions which are resistant to known attacks.

And I can't even tell what Declan meant by: To write a specific backdoor and cloak it with the same hash collision may be much more time-intensive. (2004-08-18 06:57:51.0) Permalink

20040817 Tuesday August 17, 2004

Hash crash Interesting times for cryptographic hash functions..

On Perry Metzger's Cryptography mailing list, we find first a report of a collision found in the original (never widely used) SHA function, and then the bigger report that four researchers in China have apparently come up with a general method for attacking MD4-like hash functions. Most impressively, they say about MD4:

Our attack can find collision with hand calculation.

There are also rumors of an impending announcment of a collision in SHA-1. No word yet on whether/how these methods can be extended to SHA-256/384/512; it looks doubtful that they'll be useful against HMAC-based constructions but other uses of hash functions need closer examination.

The attacks find pairs of messages which hash to the same value -- but nobody has yet revealed the algorithms in use; this is likely a much easier problem than finding a message which hashes to a fixed value. The MD4/MD5 message pairs differ only in a few bits, while the SHA1 pairs (produced by a different research group) differ by quite a bit more -- this is likely an artifact of the more complex message schedule found in the SHA series. SHA-256 and up use an even more complex message schedule.

(2004-08-17 11:14:23.0) Permalink

20040815 Sunday August 15, 2004

The Little Things. In a post the other day on the Columbia disaster, Glenn Reynolds wrote "Sometimes it's the little things that get you."

I beg to differ. In engineering, it's usually the little things at the root of failures. A large part of successful engineering involves getting enough of the details right. Most commonly, a bunch of little things, any one or two of which could be shrugged off, all go wrong at once or in sequence.

A large part of successful engineering involves getting enough of the details right that the inevitable minor failures don't build on each other and cascade into a larger failure. This is doubly so when security is a consideration... (and, as an aside, one of the reasons why I need to dive back into the IETF PKI4IPSEC discussion real soon now...)

(2004-08-15 18:15:49.0) Permalink

Calendar

« August 2004 »
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
16
19
20
21
22
23
24
26
27
28
29
30
31
    
       
Today

RSS Feeds

XML
All
/General
/IETF
/IPsec
/Music
/OpenSolaris
/Solaris

Search

Links


Navigation