[1066] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (David P. Jablon)
Mon Jun 23 21:14:33 1997
Date: Mon, 23 Jun 1997 19:08:51 -0400
To: trei@process.com, coderpunks@toad.com, cryptography@c2.net
From: "David P. Jablon" <dpj@world.std.com>
Cc: trei@process.com
In-Reply-To: <199706231946.MAA00236@toad.com>
At 03:46 PM 6/23/97 -6, Peter Trei wrote:
> I've been doing a bit of research on things that could be 'the
> next target', and I thought I'd share them with you. [...snip]
> Fine and dandy, it looks like we can easily kill RSA 512 using
> GNFS, right?
> Wrong.
I agree. Currently used public-key sizes seem pretty conservative,
and GNFS is certainly tougher to implement than simple brute-force.
But there's a *lot* of easy game out there for the picking, like ...
>Inadequately encrypting commercial software.
>
> We got a lot of bang out of brute-forcing 40-bit RC4 in the
> export version of 'Netscape Navigator' a couple years ago,
> partly because there was an identifiable and well known
> target which *had* to respond to the crack (which Netscape
> did with speed and grace). We could do this again.
Any of several widely-used challenge/response password
systems make attractive targets. A simple marriage
of a dictionary cracker connected to a strategically-placed
network sniffer, should produce an embarrasing flood of results.
But the problem with weak password methods is subtly different.
Since we can't make user-memorized keys arbitrarily large, we need
to use better methods to protect the relatively small or indeterminate-
sized space of passwords. The trick is to embarrass the manufacturer,
rather than the user.
> Producing key search apps which can brute the crypto in this
> suite would force the manufacturer to answer as to why it chose
> such poor cryptography, and produce a stronger (albeit currently
> unexportable) version. It would also light a fire under the
> manufacturer to lend it's not inconsiderable weight in the
> export battle.
In this case the manufacturer can't pass the buck. Integrity and
authentication-only solutions have always been exempt from the
nastier export controls. Several strong password methods that are
at least resistant if not immune to sniffer brute-force attack have been
known for several years, but are not yet widely deployed.
Given all the attention paid to the proper protection and use of
of stored keys, the poor user's memorized key deserves some
protection too.
------------------------------------
David Jablon
web: http://world.std.com/~dpj/
email: dpj@world.std.com
