Re: A twist on OTP for an outstandingly secure channel?
 From: rossum <rossum48@xxxxxxxxxxxx>
 Date: Thu, 11 Jan 2007 23:36:49 +0000
On 11 Jan 2007 14:09:44 0800, "JeanFrançois Michaud"
<cometaj@xxxxxxxxxxx> wrote:
Thanks for the explanation. Your system uses 40 random bytes of
John E. Hadstate wrote:
"Volker Hetzer" <firstname.lastname@xxxxxxxx> wrote in
message news:eo3k21$dnj$1@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Given a stream cipher with a key of n bits, plus m bits
detailing
how to find the message bits, where's the advantage over
the standard
solution of just using a stream cipher with a key size of
n+m bits?
I might be missing something, but I believe the OP proposed
*replacing* the bits from the key stream with plaintext bits
(not XORing them as would usually be done). If I understood
the OP's proposal, you don't need n+m bits and you don't
even need the original key stream; you only need the m bits
that tell you how to find the message bits.
It would be a combination of both actually.
Maybe a drawing will help.
random block key (assume actual random data and not $):
$$$$$$$$$$
$$$$$$$$$$
$$$$$$$$$$
$$$$$$$$$$
random bogus data with randomly 'punctured holes' (assume actual random
data and not *):
*** ******
******** *
*********
***** ****
Plaintext:
Hell
Bogus data + plaintext (assume acutal random data and not *)
***e******
********l*
H*********
*****l****
Now we XOR the key against the bogus data + plaintext (both the key and
bogus data + plaintext are of the same size).
Encrypted message (assume an encrypted output and not @):
@@@@@@@@@@
@@@@@@@@@@
@@@@@@@@@@
@@@@@@@@@@
Regards
Jeff
keystream and 36 random bytes of bogus data to encrypt 4 bytes of
message. In addition extra bytes of information on where to find the
plaintext in the bogus data have to be transmitted to the receiver.
Now consider an alternative system.
Plaintext: Hell
Pad the plaintext to 40 bytes by adding 36 bytes of nonrandom
padding:
Hell100000 1 = 0x80
0000000000 0 = 0x00
0000000000
0000000000
This is a standard padding scheme where a 1 bit is added to the end of
the plaintext and then 0 bits are added up to the required length. It
can easily be undone by removing all trailing zero bits and one
further 1 bit. What is left is the original plaintext.
We have a random key of 40 bytes:
$$$$$$$$$$
$$$$$$$$$$
$$$$$$$$$$
$$$$$$$$$$
XOR the key with the padded plaintext to give the cyphertext:
@@@@@@@@@@
@@@@@@@@@@
@@@@@@@@@@
@@@@@@@@@@
This is a standard way of padding and encoding a message.
This uses less random data, it is just as difficult to decrypt since
the OTP cyphertext is the same length, and it does not require passing
any extra information about how to extract the plaintext from the
padding.
Why would people want to use your scheme which needs almost twice as
much expensive real random data (76 bytes against 40) and requires
extra bytes to be passed as well?
rossum
.
 References:
 Re: A twist on OTP for an outstandingly secure channel?
 From: Joseph Ashwood
 Re: A twist on OTP for an outstandingly secure channel?
 From: JeanFrançois Michaud
 Re: A twist on OTP for an outstandingly secure channel?
 From: Joseph Ashwood
 Re: A twist on OTP for an outstandingly secure channel?
 From: JeanFrançois Michaud
 Re: A twist on OTP for an outstandingly secure channel?
 From: David Taylor
 Re: A twist on OTP for an outstandingly secure channel?
 From: JeanFrançois Michaud
 Re: A twist on OTP for an outstandingly secure channel?
 From: Volker Hetzer
 Re: A twist on OTP for an outstandingly secure channel?
 From: John E. Hadstate
 Re: A twist on OTP for an outstandingly secure channel?
 From: JeanFrançois Michaud
 Re: A twist on OTP for an outstandingly secure channel?
 Prev by Date: Re: About RSA implementation
 Next by Date: Cryptanalytic results on FORK256 compression function  website
 Previous by thread: Re: A twist on OTP for an outstandingly secure channel?
 Next by thread: Re: A twist on OTP for an outstandingly secure channel?
 Index(es):
Relevant Pages
