Encryption key longer than text to encrypt




Mike Amling wrote:
Jean-François Michaud wrote:
... The idea is to allow for complex
generation of 'random data' used as OTP keys XORed against plain text.
The keys could even be pre generated whenever cycles aren't used to
speed up the process (this is most probably a better solution). We
would then have machines that can generate identical OTP keys given a
synchronization cue based on an initial machine state.

That's not a OTP. Shannon's proof of security of the OTP does not
apply to your proposal. You've got a stream cipher, at best.

--Mike Amling

This makes me wonder now that I'm thinking about OTP again. I'm sure
work has been done on it already, but what about using keys that are
larger than the text to encrypt?

Since it is easier in practice to use pseudo random data than to
generate random data which is then distributed as appropriate, 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.

I'm thinking pseudo generated key and bogus data:

Key: BIOLA03IIN56DSH8VC15
Text: HELLO
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
Key: BIOLA03IIN56DSH8VC15
_________________________________________

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)?

BOB has a virtual machine with a certain rotor settings and generated a
pseudo random key and pseudo random bogus data.

ALICE also has a virtual machine with the same rotor settings which
means she can generate the same two pseudo random key and bogus data.
So she has all the information she needs to decrypt the message and
unscramble it.

All of this of course, depends on the initial rotor states being
unknown to the attackers. Would it matter If the algorithm was known?,
I'm not certain it would, but do you think it would it be 'easy' to
derive the properties of pseudo random data generation to try and
extrapolate the initial rotor position?

Regards
Jean-Francois Michaud

.



Relevant Pages

  • Key longer then the text to encrypt
    ... generation of 'random data' used as OTP keys XORed against plain text. ... Since it is easier in practice to use pseudo random data than to ... additional bogus data all the way up to the lenght of the key (maybe by ...
    (sci.crypt)
  • Re: Encryption key longer than text to encrypt
    ... generate random data which is then distributed as appropriate if we ... have OTP in mind, would ... Right stream cipher, I wasn't aware of the difference between true OTP ... bogus data. ...
    (sci.crypt)
  • Re: Encryption key longer than text to encrypt
    ... generate random data which is then distributed as appropriate if we ... have OTP in mind, would ... and stream cipher until recently. ... bogus data. ...
    (sci.crypt)
  • Re: Encryption key longer than text to encrypt
    ... generate random data which is then distributed as appropriate if we ... have OTP in mind, would ... and stream cipher until recently. ... bogus data. ...
    (sci.crypt)
  • Encryption key longer than text to encrypt
    ... Since it is easier in practice to use pseudo random data than to ... have OTP in mind, would ... encrypting messages à la OTP with 'pseudo random data' using a key ... additional bogus data all the way up to the lenght of the key (maybe by ...
    (sci.crypt)