Re: Systems with weak crypto, was: The House Rules At The Permanent Virtual

[dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)]

frantz@netcom.com (Bill Frantz) writes:
> >I also don't think that the ease of breaking the code should be the only
> >consideration in evaluating a low-end cryptographic product. ...
> >
> >... If someone wants to market (and support) a crypto package for
> >the masses and gets the masses to deploy it, I take my hat off to them. It
> >doesn't matter if the code itself can be cracked as easily as the codes used
> >in PKZIP or MS Excel or MS Word (reportedly). If the users discover that the
> >code isn't strong enough for their needs, they'll upgrade to stronger codes.
> >The path from weak crypto to strong crypto is much shorter than the path fro
> >no crypto to some crypto.
> >
> >If the user interface and [did you mean "is" - bf] logical and transparent
> >and provides hooks to
> >replace the weak (non-export-controlled) crypto being shipped with a stronge
> >one (say, by FTPing a DLL) then it's a Good Thing.
>
> Good interfaces are definitely something needed for the widespread adoption
> of crypto, either strong or weak.  However, the general opinion I have
> heard is that UIs with easily replaced crypto are covered by ITAR.

I too have heard a lot of bullshit on this mailing list with no basis in
reality.

Suppose a vendor sells (or gives away) a software product, say, a front end
to POP3/SMTP, or a secure filesystem for WinNT, with hooks to crypto
routines in a DLL (or a shared library). The vendor bundles 2+ crypto
libraries with the product, publishes the API for plugging in 3rd party
libraries, and makes a diligent effort to limit key size to, say, 16 bits.

Later a strong library becomes available from overseas (perhaps a PGP
interface.) and it turns out that the key size limitation sort of doesn't
work (e.g. disallows keys from 17 to 127 keys but allows 128+). "Sorry,
officer, a bug in our program!"

Is USG going to risk a test case on the vendor?

Suppose an organization deploys (weak) crypto and establishes policies and
procedures for distributing keys, for ensuring that all that needs to be
encrypted is, for clearing plaintexts, etc. Suppose one day it becomes
dissatisfied with the weak crypto package and replaces it by a stronger one.

How much of the time and effort invested in deploying the weak package will
be directly transferrable?

> >Don is doing a Good Thing and the "cypher punks" are doing an evil thing.
>
> If Don is contributing to better interfaces, then I agree he is doing a
> good thing.  If all he is doing is proposing a new algorithm and describing
> it with, to be charitable, non-standard uses of well defined terms, then I
> disagree.

Don promotes the use of crypto. I have no idea what exactly he's selling.
I haven't been paid to review it. :-)

> I strongly disagree that cypherpunks are doing an evil thing by exposing
> the weaknesses in anyone's (including Don's) crypto system.  There are many
> ways to contribute, and publicizing the facts about a system are one of
> them.

"Cypher punks" are doing an evil thing not by exposing the alleged weaknesses
in Don't proposal (I have no idea if they're there or not, and I don't care).
"Cypher punks" such as Paul Bradley verbally abuse Don and turn this mailing
list into a laughing stock for the media. Putting "(spit)" after Don's name
and calling him "bullshit master" is not the same as exposing weaknesses in
his proposal.

---

<a href="mailto:dlv@bwalk.dm.com">Dr.Dimitri Vulis KOTM</a>
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps