1996-01-22 - No Subject

Header Data

From: owner-cypherpunks@toad.com
To: N/A
Message Hash: a13f144843a1b1caaae937e37c3d50a1756ac4a5a5230b08ed41e3c0746c8db7
Message ID: <QQzznz03664.199601220158@relay3.UU.NET>
Reply To: N/A
UTC Datetime: 1996-01-22 04:43:55 UTC
Raw Date: Mon, 22 Jan 1996 12:43:55 +0800

Raw message

From: owner-cypherpunks@toad.com
Date: Mon, 22 Jan 1996 12:43:55 +0800
Subject: No Subject
Message-ID: <QQzznz03664.199601220158@relay3.UU.NET>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

In article <9601200326.AA09366@toad.com>, Peter Trei <trei@process.com> wrote:
> > > If they're nasty, they'll check on the receiving side as well, to
> > > ensure that the LEAF and/or the espionage-enabling key have not been
> > > patched in the sending 'International' version.
> > 
> > Nearly impossible. Why? Because they can only include the public key,
> > and not the private key, of the GAK authority in the code. You can
> > encrypt the three bytes of key, but it is very hard for a receiver
> > other than the govvies to read them. There is no shared secret
> > information or private information available, ergo, they can't check
> > their LEAF equivalent.
> 
> Think it through. 
   [suggesting that Alice encrypts 24 bits of key under NSA's public key,
    Bob repeats calculation and checks that the two LEAFS are the same]
> Thus, you can prevent a non-complying copy  of Lotus from talking to 
> a complying copy of Lotus, which is one of the goals of the GAKers.

No, you're wrong, the process you've described does not work.

Note that RSA normally is used as probabilistic encryption: encrypt the
same plaintext twice, and you'll likely get two different ciphertexts.
Thus, if RSA is used in the normal probabilistic way, the receiver can't
tell whether the sender was compliant.

Now you might suggest that the sender should not include probabilistic
padding, and use RSA deterministically, so that (somehow) the receiver
can check whether those 24 bits are correct.  That again won't work,
since a third-party eavesdropper will be able to do a 2^24 brute force
calculation to recover those 24 bits.

There are complicated ways to prevent a non-compliant copy of Lotus from
inter-operating with a compliant copy (as others on cypherpunks have kindly
pointed out), but they are complicated, and would require a re-design of
Lotus Notes' encryption module.  Since the export version is interoperable
with the non-export version, this would seem to require too much foresight
and work to be very likely.

In any event, I've heard that the export version of Lotus Notes 4 always
sends a LEAF, but the receiver never checks it.  So I think a simple binary
patch to change the NSA's public key should work.

P.S.  So does anyone know how large the NSA's public LEAF key is?
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBMQKzSyoZzwIn1bdtAQF/zAGAxODShPqrBQLsWzRVAkW7+jbVJidQIF5q
1Jyisn2EedTQoBLHnZD7ojnmws807XZK
=bRAO
-----END PGP SIGNATURE-----





Thread