1993-04-20 - Re: Another Clipper weakness

Header Data

From: Hal <74076.1041@CompuServe.COM>
To: CYPHERPUNKS <CYPHERPUNKS@toad.com>
Message Hash: 6d82752dd3b36f1c8bda905d60eee2db459dc0a406f606142e576caa2972f823
Message ID: <93042021093174076.1041_FHD64-1@CompuServe.COM>
Reply To: _N/A

UTC Datetime: 1993-04-20 21:26:00 UTC
Raw Date: Tue, 20 Apr 93 14:26:00 PDT

Raw message

From: Hal <74076.1041@CompuServe.COM>
Date: Tue, 20 Apr 93 14:26:00 PDT
To: CYPHERPUNKS <CYPHERPUNKS@toad.com>
Subject: Re: Another Clipper weakness
Message-ID: <930420210931_74076.1041_FHD64-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


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

From: "Perry E. Metzger" <pmetzger@lehman.com>

> The number N is not secret and is not random -- it is therefore not
> necessary that the PRNG generate N, and indeed N is not generated, it
> is given. Its presumably just an ordinary serial number.

Yes, sorry, I was confused about that.  N is indeed an ordinary serial
number.

> Why not just generate U1 and U2 by a more straighforward approach that
> doesn't involve strange padding and odd randomly selected constants?
> Indeed, why not just use true random numbers? Surely a radioactive
> source isn't unavailable to Mykotronix.

Again, I think the fact that the S1 and S2 are introduced by agents
of the escrow organizations is supposed to make the process appear more
trustworthy.  Since the escrow organizations must be trusted, it does
not add any weaknesses to have them creating the random seeds for the
keys.

Getting numbers from a true random source would be better in some ways,
but it would be hard to know whether the source was truly random and
was not subtly hacked by the NSA to reduce the randomness.  Verifying
the randomness of a black box could not be done easily on site.  With
the S1/S2 approach, theoretically an escrow agent could stop the process
at some point and issue a challenge, making S1 and S2 public and verifying
that the keys were in fact generated by the specified algorithm.  However,
there has been no discussion of such a challenge in the key-creation
protocol.

> Furthermore, Denning says about 300 chips are programmed in a batch
> using baroque methods in a vault. Well, folks, that just won't do if
> twenty or thirty million of these babys are being sold a year -- or
> even if just five million are sold a year. Seems to me that the
> processing is going to have to get more efficient, and likely thus
> much more sloppy.

Yes, this is a good point, although it depends on the specific numbers
of chips being produced and how long it takes to go through this process
for a batch of 300 chips.  I gather that the chips are actually programmed
in this vault, under control of the laptop computer which holds the
keys (and is then destroyed?  Ha!).  If they had a batch programmer
which actually did 300 chips in a tray, then several batches could be
done in a sitting.

There are probably a few hundred million phones in the U.S., but I
doubt that more than a few percent of them would be secure phones in
the next three or four years.  This might correspond to a production
level of a few hundred thousand chips per year, which would be a
couple of dozen batches per week.  This sounds doable.  Beyond this
point there would be problems, though.  Probably other manufacturers
would be involved by then.

Hal

-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQCVAgUBK9Q8HKgTA69YIUw3AQEYkwP/USkSY0pWeJEBXT+A8guzc+pVXJzNXExk
alGJoOLo3E9ZvJEW/e1sbO9TM1AjGnXdHrPMACqIdPUHdn+wnKE3jLBH/026ncQw
POeYBIaKuqvkV0HMkf3ebu4YXr06D9o3sapl0DnpZDm5RNUkoGpUvKpWa6EEJUDt
yBuCGiW5qsk=
=tpn9
-----END PGP SIGNATURE-----






Thread