# Re: Encryption key longer than text to encrypt

rossum wrote:
On 3 Jan 2007 06:41:46 -0800, "Jean-François Michaud"
<cometaj@xxxxxxxxxxx> wrote:

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,
No. The reason that an OTP is provably secure is that the keystream
is truly random. As soon as you substitute a pseudo-random keystream
the security proof fails. You no longer have an OTP, you have a

Right stream cipher, I wasn't aware of the difference between true OTP
and stream cipher until recently. The definition I used for a stream
cipher was biased, now I understand the distinction more clearly.

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:

------------- Keystreams:
Key: BIOLA03IIN56DSH8VC15
Bogus Data: POQ9YDK3REEVJHHHZ8LE

------------- Plaintext:
Text: HELLO

------------- Scramble:
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)?
Precisely. If you have a strong PRNG then you have a strong stream
cypher. If you have a weak PRNG then you have a weak stream cypher.

Using Enigma as a PRNG is an interesting idea. I am not so sure about

1 Using Bogus Data will increase message sizes. There are situations
where increased message sizes are to be avoided. I suggest that you
allow users to agree not to use Bogus Data if they do not want
increased message sizes.

Understandably it will depend on the context yes. It might rule out
smaller devices like smartcards. But I guess I'm not really considering
embedded devices right now, I'm mostly thinking about a desktop to
desktop application.

2 Scrambling the Message requires that the whole plaintext message be
recieved before the first character of the cyphertext can be
transmitted. This requires much more storage than a conventional
stream cypher, which only needs to store one byte of the plaintext at
a time. This will make it more difficult to put your cypher onto the
more memory restricted processors such as smart cards.

Right, but as mentioned above, I didn't really have in mind embedded
of mind. I'm thinking about desktop to desktop.

3 Since the cypher needs to be able to resist a chosen plaintext
attack, I do not see what you gain from scrambling the plaintext.

The idea is, since the PRNG is weaker than RNG used for OTP is to try
and cut down chances of text being recovered more easily by using
heuristics (since the text is scrambled). Attackers won't be able to
expect relevant text to fill in the whole encrypted message.

*****We're assuming a complex rotor machine, as complex as we want,
similar to enigma is used to yield the keystreams*****
Too complex a program will not fit into the memory available on a
smartcard or similar device.

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
data.
So she has all the information she needs to decrypt the message and
unscramble it.
I think not. Alice can use the keystream to recover Bogus Data +
Text. She can use the Bogus Data to recover *differences* between the
Bogus Data and Bogus Data + Text. This does not give her the text:

Actually, the idea is to generate 2 keystreams, both of them being
generated deterministically on both BOB and ALICE's side given that
they can both have the same virtual machine states. One of the keys
would be used as the key to unlock the Bogus Data + Text and another
keystream which is the original bogus data would be used to unscramble
text and recover it. Or maybe the scrambling/unscrambling can be a
function of the machine state after generating both keystreams. I think
this would be more secure since the machine state is supposed to remain
unknown to the attackers (it is, in essense, the key to the whole
encryption scheme).

1) The text does not appear in order, it is scrambled. In your
example, Alice does not recover "HELLO", she recovers "HOLLE" which is
the order in which the message characters appear. How does Alice know
what the scrambling order is? There is nothing in your description
about transmitting the scrambling order to Alice.

2) By chance, Alice will fail to recover 1 in 256 characters when the
character in the Message matches the corresponding character in the
Bogus Data: if the Bogus Data was "LLLLLLLLLLL..." she would recover
"HOE". How will Alice know when a character is actually a Message
character rather than a Bogus Data character?

The unscrambling/reconstruction would happen automatically as a
function of either the bogus data generated by the virtual machine or
as a function of the latest state of the virtual machine after the
latest key generation. No work on Alice's part has to take place for
her to decode the message.

Regards
Jean-Francois Michaud

.

## Relevant Pages

• Re: Encryption key longer than text to encrypt
... and stream cipher until recently. ... bogus data. ... I'm thinking pseudo generated key and bogus data: ... Encryption by XORing Key to Bogus Data + Text ...
(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)
• 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)