[117288] in Cypherpunks

home help back first fref pref prev next nref lref last post

RE: ACTION ALERT: Crypto Legislation

daemon@ATHENA.MIT.EDU (Anonymous)
Mon Aug 30 22:01:22 1999

Date: Tue, 31 Aug 1999 03:40:40 +0200 (CEST)
Message-Id: <199908310140.DAA32003@mail.replay.com>
From: Anonymous <nobody@replay.com>
To: cypherpunks@cyberpass.net
Reply-To: Anonymous <nobody@replay.com>

> SEC. 14. FAILURE TO DECRYPT INFORMATION OBTAINED UNDER COURT ORDER.
>
>     Whoever is required by an order of any court to provide to the court
> or any other party any information in such person's possession which has
> been encrypted and who, having possession of the key or such other
> capability to decrypt such information into the readable or comprehensible
> format of such information prior to its encryption, fails to provide such
> information in accordance with the order in such readable or
> comprehensible form--
>             (1) in the case of a first offense under this section,
>         shall be imprisoned for not more than 5 years, or fined under
>         title 18, United States Code, or both; and
>             (2) in the case of second or subsequent offense under this
>         section, shall be imprisoned for not more than 10 years, or
>         fined under title 18 United States Code, or both.

Okay, time to fire up the old coding tools and get to work on...

DENIABLE ENCRYPTION, Canetti et al, Crypto 97, p90, available at
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/deniable_abs.html.

The idea is to encrypt a ciphertext such that it can be decrypted in
two or more different ways.

Here are a couple of trivial methods, one of which would actually be
practical.

The first is to use a One Time Pad (OTP).  It is well known that with a
OTP, any ciphertext can be decrypted as any plaintext.  Just construct
your fake key to be the xor of the two.  However OTPs are not usually
practical.

Another simple method is as follows.  It uses "symmetric" encryption
(e.g. 3DES), not public key encryption.

Conceptually, there are two modes of operation: deniable and undeniable.
The undeniable mode is the normal one, and in that mode you can only
decrypt the ciphertext legitimately.  The deniable mode allows you to
decrypt one of two different plaintexts.  In actuality, you always use
the deniable mode, but you pretend that you usually use the undeniable
mode and have the deniable program around just for fun or just for
occasional use.

The form of an undeniable message is just a ciphertext plus an equal
sized block of random data.  The random data may be either before or
after the ciphertext.

If you are forced to decrypt an undeniable message, you simply reveal
the key and it can be tried against each half of the message.  One half
decrypts to garbage (the random half) and the other half decrypts as
your true plaintext.

In deniable mode, what you do is to have two keys, encrypt the real
plaintext with one of them, and encrypt a cover (fake) plaintext with
the other one.  Make the two plaintexts the same length.  Then put the
ciphertexts side by side.

When you are compelled to decrypt, you claim that you were using the
undeniable mode (in which there is a real ciphertext plus garbage),
and reveal the key to the fake plaintext.  When applied to both halves
of the message, one half is garbage and one is the cover message.  It
looks like an undeniable-mode message with innocent content.

The attacker may suspect that the other half of the message isn't really
garbage, but actually is a ciphertext that he is interested in.  But he
can't prove it and technically you are complying with the bill above by
providing what you can claim is the key and the ciphertext.

It's even better if you do occasionally send an innocuous message using
the undeniable mode, so that you really can't decrypt the other half of
the data.

The down side is that the messages are twice as big, but who cares
these days.  Any text message can be doubled in size and the bandwidth
is negligible.  Plus with MIME security and encryption plug-ins you
never even see the ciphertext.

One big practical problem is the use of symmetric encryption, which
requires some method for exchanging keys between the users.  You'd
probably want to use the same keys for an extended period of time,
one used to encrypt sensitive data and one used to encrypt cover data.

There is always the risk that when you do exchange keys, say by using
a public key method, that that could be eavesdropped and you could be
forced to reveal what you did there.  That is where the paper above
comes in handy.  It shows a public key encryption system which can be
fake-decrypted as any message whatever.  It's a little too technical
to describe here, and has some disadvantages (message expansion, extra
required messages).  But if used occasionally to exchange long term
symmetric keys used with the method above, it could provide a basis for
routine use of deniable encryption.

More information can be provided about that method if desired.


home help back first fref pref prev next nref lref last post