[1079] in cryptography@c2.net mail archive
Re: Thoughts on the next target.
daemon@ATHENA.MIT.EDU (David P. Jablon)
Tue Jun 24 16:21:49 1997
Date: Tue, 24 Jun 1997 16:03:07 -0400
To: "Marcus Leech" <mleech@nortel.ca>
From: "David P. Jablon" <dpj@world.std.com>
Cc: cryptography@c2.net
In-Reply-To: <199706240159.AA187817594@bftzh114.ott.bnr.ca>
Marcus,
I think you advocate a too-narrow approach to targeting
and exposing bad crypto security.
I wrote:
>> Any of several widely-used challenge/response password
>> systems make attractive targets.
You replied:
>Many of these systems (CryptoCard, etc) use DES in one mode or another,
> and the ones that don't use DES use a proprietary hash function.
Even if triple-DES or SHA1, if it's used inappropriately, say
for ordinary challenge/response authentication of a password,
then the method is weak.
>I think it's "splashier" to demonstrate weakness in widely publicized,
> and widely used (in the used-in-more-than-one-application sense)
> algorithms.
I disagree. *All* widely used methods are splashy and important
targets, regardless of whether the technical details are public, and
regardless of "how many" applications use the method. Fortunately
for us, there are *lots* of widely used lame systems, though many
if not most use unpublished methods. To ignore these or pretend
that they either aren't newsworthy or aren't a threat seems cowardly.
> Brute-forcing the SecurID hash algorithm, for example would require
> that someone violate their license agreement with Security Dynamics/RSA.
> "Algorithm Thieves today showed that SecurID cards aren't as secure
> as manufacture claims".
It's sad when security relies on these agreements. But I wasn't
particularly thinking of SecurID. There are much more attractive
targets, which are only protected by shrink-wrap "agreements"
against reverse engineering. As far as I know, these have zero
power. Reverse-engineering is a time-honored and
courtroom-sanctioned privilege for buyers of off-the shelf
technology, when no signature below the fine print is required.
For example, I'm thinking about unwitting users of certain
network operating systems, who say, plunk themselves
down on a new broadband cable network. Even if they click all
the right buttons during installation, they are still sharing a network
with friends or foes that can eavesdrop and perform brute-force
attacks.
If we only target vendors of open, fully documented,
non-proprietary solutions, then the less-sincere vendors
will seek refuge in the dark corners of security through
obscurity. They at least need to be exposed.
------------------------------------
David Jablon
web: http://world.std.com/~dpj/
email: dpj@world.std.com
