[2343] in cryptography@c2.net mail archive
Re: Chaffing and winnowing - efficiency improvements
daemon@ATHENA.MIT.EDU (proff@iq.org)
Tue Mar 24 13:21:52 1998
From: proff@iq.org
In-Reply-To: <199803231813.LAA10397@nyx10.nyx.net> from Colin Plumb at "Mar 23, 98 11:13:26 am"
To: colin@nyx.net (Colin Plumb)
Date: Tue, 24 Mar 1998 15:37:26 +1100 (EST)
Cc: cryptography@c2.net
> From cryptography-owner@c2.net Mon Mar 23 20:54:44 1998
> Delivered-To: proff-cryptography@iq.org
> X-Authentication-Warning: blacklodge.c2.net: majordom set sender to owner-cryptography@c2.org using -f
> Date: Mon, 23 Mar 1998 11:13:26 -0700 (MST)
> From: Colin Plumb <colin@nyx.net>
> Message-Id: <199803231813.LAA10397@nyx10.nyx.net>
> X-Nyx-Envelope-Data: Date=Mon Mar 23 11:13:26 1998, Sender=colin, Recipient=cryptography@c2.net, Valsender=colin@localhost
> To: cryptography@c2.net
> Subject: Chaffing and winnowing - efficiency improvements
> Sender: owner-cryptography@c2.net
> I can make a couple of observations. One is that since the MAC
> attached to chaff packets is arbitrary, you might as well use the
> wheat's MAC. E.g. you'd send (0,0,4529), (0,1,4529), (1,0,2752),
> (1,1,2752), (2,0,9136), (2,1,9136), etc.
>
> This, however, lends itself to the obvious compression technique of
> omitting the actual data bits and sending just (0,4529), (1,2752),
> (2,9136), etc. Rivest's Charles, along with a friend (Dawn) at Bob's
> end, could easily convert Alice And Bob's legitimate communications to
> this form, and Dawn could generate the redundant packets to try at the
> far end.
Not really, since the bits are pretty insignificant (in length)
compared to the hash. You could make a further cpu/space trade off by
"storing" 8 bits in the hash (instead of one), and then "breaking" the
8 bits by doing 256/2 (avg) hash computations.
The whole scheme makes me feel a little uncomfortable insofar as
related plaintext attacks on the hash algorithm are concerned.
Using a more analysable algorithm like DSA isn't practical. One
of the posts talked about provable security - this is nonsense,
the security of the scheme has just moved into the hash algorithm.
> This is getting *closer* to practical. Of course, anything is
> practical if nothing better is available due to GAK.
Right, but the problem is Rivist's scheme doesn't really have much
merit *except* for defeating GAK (the cryptographic deniability
is nice, but other more effiecient schemes address that issue),
and regulations (as opposed to legislation) can change very quickly.
Cheers,
Julian.
