Re: A twist on OTP for an outstandingly secure channel?

On Sun, 07 Jan 2007 10:48:57 +0000, rossum <rossum48@xxxxxxxxxxxx>
wrote:

On 6 Jan 2007 22:47:04 -0800, "Jean-François Michaud"
<cometaj@xxxxxxxxxxx> wrote:

Discussing about rotor machines/stream ciphers on another thread, I was
wondering what other people thought of this idea.

Imagine an OTP. Lets say 2KB of perfectly random data (key) and another
(2KB - 24 bits) of perfectly random data (used for padding). 3
character from the plaintext message are inserted where the missing 24
bits would be (assuming 8 bit characters. The missing 24 bits could be
dispersed around as randomly as the random padding data to avoid
sequential plaintext data). Now imagine that through some miracle the
attacker is able to brute force through all the keys and has all the
possible decryption at his disposal for every encrypted message
(imagine a message 15 characters long for example, this would yield 5
encrypted messages, sent across). What is the initial assumption? Full
message length, he gets nowhere.

Now imagine we give the attacker invaluable information. The
information that only 3 characters of plaintext are encrypted but he
doesn't know where. What can he do? He has to figure out what those
characters are through as many unencrypted messages as the keyspace is
large and he has to try out every combination of blocks of 3 characters
per keyspace across each keyspace per intercepted messages ranging over
a whole slew of messages (5 in our example). We have a combinatorial
explosion that is many orders of magnitudes greater than what standard,
straight up, OTP itself allows as far as protection goes. We are
magnitudes beyond being "unbreakable".

Am I missing anything?

I'm thinking that a similar scheme would be extremely useful in
compensating to the looser encryption strenght of stream ciphers. And
If the idea is sound, I would even go as far as saying that key
information exchange could be performed very safely through such a
channel.

Regards
Jean-Francois Michaud
Padding can be useful in the context of a stream cypher/OTP in order
to conceal the actual length of the plaintext. If the only possible
messages are "YES" and "NO" then concealing the length of the message
is very important. Your scheme has a far higher ratio of padding than
is neeeded just for this purpose, "YES" and "NOX" would suffice in my
example.
A further thought on this. For an OTP the major practical problem is
getting the key from Alice to Bob. If you are going to bury the
message in a large quantity of padding then this problem is magnified.
With your proposed padding scheme every three bytes of message results
in 2 KB of cyphertext, and hence the OTP key will be 2 KB of key for
every three characters of plaintext. This will only exacerbate the
existing OTP problem of secure key transfer for very little gain.

rossum

In your scheme the crucial thing is exactly how Alice disentangles the
plaintext from the padding. If it is a fixed unkeyed algorithm then
the attacker can be assumed to know the algorithm and the padding adds
no uncertainty to the attacker. If it is a keyed algorithm, then you
will need to transmit the unpadding key to Alice, for which you will
need to use a different cypher since she does not have the padding key
to fully decypher the padded OTP. This overcomplicates the system.

Most (?all?) padding schemes in actual use rely on a fixed unkeyed
algorithm and are there either to conceal the actual length of a
message or to extend it to the next block boundary. They do not
increase the difficulties of the attacker, except in the matter of
deriving plaintext length from the cyphertext length.

rossum

.

Relevant Pages

  • Re: A twist on OTP for an outstandingly secure channel?
    ... bits would be (assuming 8 bit characters. ... sequential plaintext data). ... Now imagine that through some miracle the ... Your scheme has a far higher ratio of padding than ...
    (sci.crypt)
  • Re: A twist on OTP for an outstandingly secure channel?
    ... Imagine an OTP. ... character from the plaintext message are inserted where the missing 24 ... bits would be (assuming 8 bit characters. ... You've not mentioned any missing bits? ...
    (sci.crypt)
  • Re: Encryption key longer than text to encrypt
    ... the generated keystream is completely ... keys that exceed plaintext in a context where plaintext is intermixed ... an OTP does not use a generated keystream but uses a very ... against statistical analyses of decoded text by using your padding. ...
    (sci.crypt)
  • Re: A twist on OTP for an outstandingly secure channel?
    ... Imagine an OTP. ... bits would be (assuming 8 bit characters. ... Now imagine that through some miracle the ... compensating to the looser encryption strenght of stream ciphers. ...
    (sci.crypt)
  • Re: A twist on OTP for an outstandingly secure channel?
    ... bits would be (assuming 8 bit characters. ... randomly punctured 'holes' in blocks of 8 bits". ... the key and the ['padding data' + 3 characters] can be XORed against ... Brute force doesn't work in an OTP scenario. ...
    (sci.crypt)