Re: Encryption key longer than text to encrypt

Ignacio aecbi wrote:
On 3 Jan 2007 12:03:07 -0800, "Jean-François Michaud"
<cometaj@xxxxxxxxxxx> wrote:

Unruh wrote:
"=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=" <cometaj@xxxxxxxxxxx> writes:


Unruh wrote:
"=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=" <cometaj@xxxxxxxxxxx> writes:


rossum wrote:
On 3 Jan 2007 06:41:46 -0800, "Jean-Fran=E7ois 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 =E0 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
stream cypher instead.
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
_________________________________________
So, not only do youhave to get the key to the recipient, you also have to
tell them how to unscramble the real message from the bogus.

The great advantage of the OTP is that ANY message is a potential message.
There is no way for the attacker to know which of these the real message
is. The disadvantage is that a huge amount of key must be sent to the
recipient ( th whole random stream). YOu decrease the key bu having to only
send the key for the stream generator, but now have increased it by having
to also send the scrambling algorithm so the recipient to disentangle the
message from the bogus.
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
scrambling the plaintext or about padding with bogus data.
Enigma is slow. Enigma is a substitution cypher, not a stream generator.

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.
Please don't think about using this for anything. It is good for you to
play with. But do not foist your own ideas onto some poor gullible
purchasers or users.
Are you dense? How many times did I say I was having fun with the idea?
Wait, lets just see you saying the same thing again in another post.
No, you are.. "I was thinking about a destop to desktop application" is NOT
" I was having fun with the idea".
Hahaha, how are you even able to think about anything? You're mind is
so closed to new information.


I don't know, I didn't develop it but it's not difficult to image and
is equally easy to implement. Why don't you ask questions to clarify
meaning instead of acting like a complete ass? This is proof that you
aren't looking to understand anything outside of the context that you
understand.
No it is proof that youhave no idea what you are talking about, whther in
the context of "having fun" or anything else.



You conveniently skipped the fuller explanation:
"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
And how are they sure that they have the same virutal machine states? Is
the mixing algorithm determined by those key streams?
They of course have to start with the same initial configuration,
otherwise a synchronize cue could be sent so that machines become
synchronized.

Jean-Francois Michaud

Even just a scrambled mix of 2 legible plaintexts provides some
protection. Context clues to one of the plaintext keys could then be
sent that were much shorter than either of the legible plaintexts.

Of course in this situation if your cleartext key is more than one or
two characters it is going to get recognized.


NO! NO! and NO! (With the maximum amount of emphasis - Seriously and importantly never do that!) a scrambled mix of two plaintexts provides almost no protection.

If you don't want to believe me you could look up the FISH cipher from WWII. When operator errors gave two messages encrypted with the one key it was broken BY HAND.

The relationship between FISH and what has been suggested to you is that with FISH the cryptographer had to first combine the ciphertext together in such a way as to cancel out the key (xor or subtraction - I forget which).

What you have been advised to do actually does the cryptographer's first step for them!
.

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)
  • Encryption key longer than 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 ... 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)
  • 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)