Encryption key longer than text to encrypt
- From: "Jean-François Michaud" <cometaj@xxxxxxxxxxx>
- Date: 3 Jan 2007 06:41:46 -0800
Since it is easier in practice to use pseudo random data than to
generate random data which is then distributed as appropriate if we
have OTP in mind, would
encrypting messages à la OTP with 'pseudo random data' using a key
greater than the message make any sense to increase security, given
that the data be scrambled evenly across and maybe padded with
additional bogus data all the way up to the lenght of the key (maybe by
using the bogus data to determine how the plain text message should be
distributed amongst the bogus data)?
This process is akin to steganography except the message is known to be
encrypted amongst a sea of junk.
We're basically talking about a synchronous stream cipher algorithm in
which the keystreams used is larger than the text to encrypt when
plaintext is scrambled across the width of the key and is padded with
bogus data (another keystream of identical length).
I'm thinking pseudo generated key and bogus data:
Bogus Data: POQ9YDK3REEVJHHHZ8LE
H position 1 in bogus data
E position 15 in bogus data
L position 14 in bogus data
L position 9 in bogus data
O position 4 in bogus data
Bogus Data + Text: HOQOYDK3LEEVJLEHZ8LE
Encryption by XORing Key to Bogus Data + Text
How cryptographically strong is such a scheme (it would of course
depend on the pseudo random data generation)?
*****We're assuming a complex rotor machine, as complex as we want,
similar to enigma is used to yield the keystreams*****
BOB has a virtual machine with a certain rotor settings and generates a
pseudo random streamkey and pseudo random bogus data. Encrypts plain
text as proposed above and send it to ALICE.
ALICE also has a virtual machine with the same rotor settings which
means she can generate the same two pseudo random streamkey and bogus
So she has all the information she needs to decrypt the message and