[6710] in cryptography@c2.net mail archive
Re: hiding plaintext
daemon@ATHENA.MIT.EDU (Bill Stewart)
Fri Mar 3 22:53:12 2000
Message-Id: <3.0.5.32.20000303174726.00b3b140@idiom.com>
Date: Fri, 03 Mar 2000 17:47:26 -0800
To: Russell Nelson <nelson@crynwr.com>, Cryptography <cryptography@c2.net>
From: Bill Stewart <bill.stewart@pobox.com>
In-Reply-To: <14525.29182.66306.102858@desk.crynwr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 02:54 PM 03/01/2000 -0500, Russell Nelson wrote:
>The essence of the above algorithm (let's call it BP1, for Buried
>Plaintext 1) is to force the decryption trial to be iterated until the
>buried plaintext is found. It means that the decryption engine needs
>to have the full crypttext available to it. If you can decrypt a
>message in N steps, then using BP1 with half random data forces you to
>do N*2 steps, where the steps themselves are more complicated. The
>storage requirements are higher, as are the data transfer pathways.
I'm not convinced that this is a big win compared to CBC with a random IV,
which also forces the cracker to crank the crypto step an extra time.
For many popular crypto algorithms, such as N-DES, Blowfish, even RC4,
the key scheduling takes more time than cranking the algorithm
(though there are ways to avoid that with 1-DES),
and you know that once you find a SOT, that's the starting point,
though if you've got the wrong key, 1/256 bytes will be SOT.
Where it does become interesting is
padding messages to resist traffic analysis, e.g. in remailers.
this lets you include random-length padding, which means that
knowing message sizes doesn't tell the traffic analyst very much.
Thanks!
Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
