From: tcmay@netcom.com (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: 56368a1d52be41059897c0afdd3bd62ffb9b56e4ca963931aafa926e91cf51b1
Message ID: <199402071757.JAA17170@mail.netcom.com>
Reply To: <199402071710.JAA29030@jobe.shell.portal.com>
UTC Datetime: 1994-02-07 18:00:36 UTC
Raw Date: Mon, 7 Feb 94 10:00:36 PST
From: tcmay@netcom.com (Timothy C. May)
Date: Mon, 7 Feb 94 10:00:36 PST
To: cypherpunks@toad.com
Subject: Defeating Clipper and Skipjack is Still Possible
In-Reply-To: <199402071710.JAA29030@jobe.shell.portal.com>
Message-ID: <199402071757.JAA17170@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain
(I've changed the article title to reflect my point here.)
Hal Finney writes:
...
> This could explain a lot. In particular, if they can enforce this, it
> could put an end to the dreams of multiple encryption. For months people
> have been saying, "Clipper? No problem. I'll just encrypt with PGP then
> pass it through Clipper and the Feds won't ever guess! Ha, ha, ha!"
>
> Maybe this won't be so easy. From Blaze's description it sounds like
> such devices wouldn't be approved. It could be the only Clipper phones
> will be ones that don't do anything to keep the Feds from picking up the
> conversation.
>
> People could still build non-Clipper encrypting phones (assuming that
> the constant rumors of threatening midnight visits from NSA agents are
> false), but the users of those phones could no longer blend in with the
> Clipper traffic.
For voice use, this may be so (but I think pre-encryption before
Clipper is still possible....see discussion at the end). But for the
forthcoming _data encryption_ use (Skipjack, etc.), I don't see how
"pre-encryption" can be detected, much less blocked, banned, or
otherwise interfered with. After all, "data are data."
Frankly, it has always been the (presumably) impending restrictions on
data encryption that have worried me the most, because it is the
application of strong crypto to data encryption that holds the most
promise (in such things as digital money, remailers, all the stuff we
deal with here on this list). Voice scrambling has never been a high
priority for me, personally.
Requiring Skipjack encryption for all packets entering the Federal
Interstate Dataway (tm) could be a constraining hassle, but what's
_inside_ those Skipjacked packets could be arbitrary. (Even an
"entropy" filter as part of Skipjack--an implausible
complication--could easily be defeated.)
If the government requires Skipjack, I can't see any way of preventing
pre-encryption, short of "random searches" (analogous to random
searches of cargo to detect contraband, etc.).
And I suspect some clever work could allow pre-encryption even with
Clipper. After all, if the canonical (expected) mode is for two
Clipper users to be speaking English to each other, and they start to
speak Croation, this is a crude form of encryption (security through
obscurity, for a few minutes at least). Even more so if they started
speaking their own private code. Clipper would just take the audio
signal, manipulate it as it is supposed to, send it, etc.
Thus, putting one's own cipher system in _front_ of Clipper (and
_after_ it at the receiving end, of course) should work, providing the
output of the cipher system is standard audio (constrained by the
phone system(s) used). But isn't this exactly what existing secure
phones are (like the STU-III)?
That is, nothing inside the Clipperphone need be touched or interfaced
with. Just use the Clipperphone as usual, but speak in a "language"
that cannot be deciphered by the surveillors, even if they get a
warrant to look at the Clipper keys.
Am I missing something?
--Tim May
--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power:2**859433 | Public Key: PGP and MailSafe available.
Return to February 1994
Return to “tcmay@netcom.com (Timothy C. May)”