[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiple-file encryption
>Date: Mon, 04 Oct 93 14:29:44 MDT
>From: "Mike Johnson" <[email protected]>
>Message-Id: <[email protected]>
>Subject: Re[2]: POISON PILL
>Yes. Make "noise addition" (really multiplexing) part of the cipher. You
>could throw away every other bit based on the parity of the key. The
>ciphertext would be twice as big, but if you compressed both plain text
>streams first, this effect might not be very obvious. Of course, if your
>encryption program were disassembled, you might be found out...
Yup -- I was assuming no padding.
If you allow padding, I already have a secret-key cipher which uses random
padding in order to frustrate known-plaintext attacks. My favorite method
uses a key to initialize a PRNG whose output gives the number of bytes of
each stream to put in the output stream -- then encipher the PRNG key
followed by the multiplexed stream. One of the streams being multiplexed
(and there can be a huge number, if you're encrypting an archive, for
example) can and should be random -- so that if you make a small change
and re-encrypt, you don't end up with cribs.
For this purpose, you'd need to have several files hanging around your
machine of random numbers yet to be used for padding.
Meanwhile, I have several files of random numbers which I keep around for
running simulations.
My favorite random number generator is
compress - </dev/audio | idea | tran | idea | tran | idea
where the idea keys are chosen randomly and there's no mic plugged in
at /dev/audio.
Other people might generate random numbers other ways. :-)
[but you might keep my method around, for demonstrating to the cops.]
- Carl