ietf-openpgp
[Top] [All Lists]

Re: Proposed Extensions to TLS for OpenPGP

1997-12-31 15:20:11
Will Price <wprice(_at_)pgp(_dot_)com> writes:
At 11:15 PM -0800 12/30/97, Eric Rescorla wrote:
Will, I'm not particularly interested in debating protocol
level crypto policy here. However, the crypto export laws
are reality for most people here, and I find your attempt to
imply that they're easily worked around fairly disingenuous.

Easily?  If you got the impression from my message that it was easy, I
suggest you read it again.  What you imply here is that you need an easy
solution.  If you were willing to do something slightly less than easy, you
might find another solution as other companies have.  This issue is at the
very core of secure software.  If it isn't done right, nothing is.  Use of
40 bit scrambling is exactly the kind of issue on which companies making
security products cannot use the easy solution.
No, what I imply here is that the solutions you propose are unworkable.
I don't really see any evidence to the contrary.

Will Price <wprice(_at_)pgp(_dot_)com> writes:
It's hard to believe that this is really going to work for many
real programs. Have you seen the size of Netscape lately. Have
you noticed how often Netscape ships new versions? (I'm not
trying to pick on Netscape here. IE has similar characteristics.
There are plenty of other big programs but web browsers hae
particularly fast release cycles.)

Have you seen the size of PGP 5.5.3 on 10 different platforms lately with
all the GUI code?  It's not exactly small. 
I don't own a copy of PGP, however, your web site says that:
Note: The Unix Binary versions vary in size from 1.3MB to 1.5MB.
The latest version of Netscape on my machine is 8 megabytes.

These just aren't commensurate.

insecure.  Such stories reduce user faith in everybody's security products.
The only solution is public code review.
It's not obvious this makes much of a difference. Note that Sendmail
source code has been widely available since the beginning.

Nobody trusts sendmail.  Nobody needs to trust sendmail if they use secure
mail.
You're getting bogged down in the comsec mentality. Sendmail is a
nightmare from a systems security perspective. 

 Secure systems are built to be simple enough to comprehend fully so
that reviewers can analyze it fully.  Sendmail clearly doesn't fall into
this category.  Everyone knows sendmail is buggy, so nobody wastes their
time trying to document every bug.
This statement is incorrect. There has actually been quite a concerted
effort to fix the security bugs in Sendmail. It's just been an utter
failure since there seem to be a nearly infinite number.

Some companies will undoubtedly never bring themselves to implementing one
of the above systems and will thus be relegated to snake oil security
internationally until the laws in the US change.
I think it's unreasonable to say that 40 bit crypto is "snake oil".
It's exactly as strong as advertised. There's no secret about the
situation.

There is no "advertising" of it.  The users are simply unaware --
effectively making it a secret.  When was the last time you saw a big
company putting a very visible warning about 40 bit security inside its 40
bit product?
Uh, let's see. When you pull down Document Info in Netscape, it says:
Security:
   This is a secure document that uses a medium-grade encryption key suited for
   U.S. export (RC4-40, 128 bit with 40 secret).

Hard to get more clear than that.

I know I've never seen something like that.  Further, even
the strong crypto products are infected by the weak crypto products in
protocols like S/MIME and SSL which require both sides to use the same
algorithms.  No warning is given in those cases either in any of the
products I've examined.  It leads to a cascade effect wherein the vast
majority of users end up having no security when they think they do have
security.  The deceit here is that even when users learn about 40 bit
security, they think it is still encryption.  Realistically, it just isn't.
This is a religious statement, not a technical one. Actually, the work
factor to break a 40 bit key is substantial. For example, Damien
Doligez's crack took the following resources:
        The 40-bit secret part of the key is 7e f0 96 1f a6.  I found
        it by a brute force search on a network of about 120 workstations
        and a few parallel computers at INRIA, Ecole Polytechnique, and
        Ecole Normale Superieure. The key was found after scanning a little
        more than half the key space in 8 days.

40 bit is next to worthless against a dedicated attacker. However,
there certainly are applications for which it is sufficient. Horses
for courses and all that.

Perhaps, but you haven't suggested any.  
I
suggested three each of which is completely workable and in use by
real companies as big as Sun.  It isn't clear how you say that I
have not suggested any when there are very clearly three
alternatives suggested.  If these don't work for you, I suggest
seeking legal advice.  There are many other roads that haven't yet
been travelled.  Don't look for the easy solution, look for the
right solution.
Hmmm... I'm not convinced that any of these is really workable.

Try to solve the following two examples:
Netscape and Microsoft. Netscape has downloads off their web site.
They want them to be easy. That means that the user can just
point and click. That means the crypto must be exportable or none
at all. Which do you suggest?
Next consider Microsoft. They embed their browser in the OS (at
least for now.). They want to ship that to foreigners. Again,
the crypto has to be exportable or nonexistent. Which do you
suggest?

So, what do you suggest these companies do?

-Ekr



-- 
[Eric Rescorla                             Terisa Systems, Inc.]
                "Put it in the top slot."