Re: Encryption key longer than text to encrypt



On 5 Jan 2007 04:53:03 GMT, Unruh <unruh-spam@xxxxxxxxxxxxxx> wrote:

run_signature_script_for_my_email@xxxxxxxxxxx (laura fairhead) writes:

On 3 Jan 2007 09:49:14 -0800, "=?iso-8859-1?q?Jean-Fran=E7ois_Michaud?=" <cometaj@xxxxxxxxxxx> wrote:


laura fairhead wrote:
On Wed, 03 Jan 2007 16:44:30 +0000, rossum <rossum48@xxxxxxxxxxxx> 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.


Hi,

Hello Laura,

I always wonder about this "provably secure". I don't remember seeing
a convincing proof of security for OTP, does anyone have any references?

I believe you're looking for Shannon's proof of security. There's some
information here about it.

http://en.wikipedia.org/wiki/One-time_pad


Hi,

Thankyou, I found a copy of his 1949 work and busy reading.

For example, a true random number generator could on one particular run
generate a sequence entirely of zeros. Examining the data would then
reveal the original cleartext. Yes it's extremely unlikely to happen
in practise I know (in practise it's probably much more unlikely to happen
than it should even in theory). But it's because of the chance of that
and then a whole series of progressively weaker cases that I would be
inclined to think OTP really isn't 100% secure ...

It's an interresting angle, but the idea behind true random generation
is that given a keyspace, each key has an equal probability of being
generated and as thus, attacks based on trying to find patterns between
captured ciphers is impossible. Even a stream of all 0s would, in such
a context, yield a strong encryption since one can't expect for an all
0 stream key to have a stronger probability of being generated than a
key of all 1s. There's a non zero probability that any plaintext will
look like any other plaintext of similar size given a proper key.

Yes this is true, it wouldn't work by itself because "you don't know"....
I mean I did read a proof about this some time ago probably and I think
I really already understood this idea, maybe I was going a little astray here
with that example, cheers for you and others to point this out; but what
drives me is a bit deeper than this, so I'm still not satisfied <g>

For example; if you use sampled conversation as the OTP then someone could wade
through looking for patches where the sound had faded (all zeros) of course they
know something about the original message.

Well yes this is "far off" from a random device but how random do you need to be to
eliminate the attack vector to zero? What I was looking for/expecting in a proof was
something showing a "snowball" effect at some threshold where the attack vector
goes from significant to insignificant. Just saying OTP with "true" random number
= 100 % secrecy has never convinced me and it still doesn't.

Convinced you of what? Of the proof? Well, if you do not believe the proof
I would suggest you think and study more. If you mean that the proof does
not say anything about how far away from truely random the key stream needs
to be before significant information bout the message can be leaked, the
answer is that noone knows the answer, or even how to phrase the question

Hi,

It's not so much that I harbour some irrational belief in the invalidity
of the proof, sorry if I gave such an impression. I have read the commonly
available explanation of its impenetrability before and it wasn't good
enough for me then. I see a number of serious problems. One point
is that any intercepted cryptogram by its very nature gives away the time of
the communication and an upper bound for the length of the plaintext.
By definition, at least, you need a layer of concealment to go from, pressumably
99.9% secrecy to 100% because of this. But this is something quite obvious
and in normal use does not give very much information to the attacker.

There are less obvious problems, the worst of all being that this proof
is nowhere near enough for me to build an OTP system with the assurance
of 100% (or close ) secrecy. For that I would need something much more
solid and I've got an idea that it may be similar difficulty to finding
a UFO.....

If a top chess player is winning consistently against everyone because
is employing a new methodology that nobody had worked out before do
they publish it? Well, in chess it is possible because the amount of
money you can earn from selling a few thousand books is probable more
than what you can earn from prize money in this game. But in the security
domain I think is quite different the situation. The effect of publish
has an effect on everyone else in the sector and then all the clients of
the technology and maybe some of them are quite unhappy if that technology
suddenly fails with a crashing sound so,... so it is quite possible you
can make much more money by to keeping it (semi)secret hehehe :)

What do you do about the locale problem?;

(possibly a scene from blakes7 :)

- Can you tell me why our cipher machines are allowing are
enemies to read all of our communications, with no effort at all?

- Madam, it cannot be a problem with the technology. The machines
are perfect.

- Well that does not explain the fact that all of our communications
can be read with no decoding effort at all! Your confounded machines
are sending our data with no encipherment at all, let alone the
rebels, even our service scouts can listen to top secret classified
broadcasts as if they were tuning into some entertainment channel!

- Madam, may I state again clearly the machines are very advanced technology
and it is impossible for them to fail. They use a true random number
generator module that has been developed over a period of some 50,000
years by the Averex co-operation on planet 9. Random numbers are really
quite strange things Ma'am, if we throw a dice 1,000 times we do not
expect to get 1,000 sixes but with truly random numbers this actually
happens sometimes. Sometimes it even happens for 1 million times or
more. What we are seeing here is what we call a "locale hit".

- Why am I surrounded by complete buffoons! It matters not to me what
peculiar properties may abound in the machines we have contracted
from you, it matters not to me what theoretical deliquencies happen
to appropriate themselves in the annuls of cryptography, it matters
simply to me, young man, that our top secret communications are not
read by our enemies or in fact by anyone except those who are the
authorized recipients. And *your* cipher machines are not fufilling
this aim. Guards! Take this *fool* away ....

And likewise, a truly random machine would not sell because of this problem
of course the assurance that because we happened to have a sequence of 2 million
zeros means nothing about what happens next is not going to wear well because
of human "common sense".

Yes, this does not seem to present significant difficulty really, as given
anyway but there is a point....

properly. HOwever a really tiny bias in RC4 is sufficient to cause the
community to strongly suggest that RC4 not be used for anything new
anymore.

Well yes you don't want any information leakage - irregardless of what one
believes the enemy could do with it in from a general point of view.
In a specific case it could give vital information. In general not even
being able to decipher one bit of the plaintext, if the attacker can just
discern some property about it, that itself may be enough to give away
crucial, sensitive information. So a cipher is trying to protect this
also.

bestwishes
l





Anyway thanks again for pointing me to Shanon, I've read a little before from him
but I read his bio this time and seems like quite an interesting character :)

bestwishes
laura












Regards
Jean-Francois Michaud


--
echo alru_aafriehdah@xxxxxxxxxx |sed 's/\(.\)\(.\)/\2\1/g'

--
echo alru_aafriehdah@xxxxxxxxxx |sed 's/\(.\)\(.\)/\2\1/g'
.



Relevant Pages

  • Re: Encryption key longer than text to encrypt
    ... 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 ... look like any other plaintext of similar size given a proper key. ...
    (sci.crypt)
  • Re: Encryption key longer than text to encrypt
    ... have OTP in mind, ... Forget about OTP. ... true random data 24/7 and insert messages when ever they have to. ... Thats an interresting idea. ...
    (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)
  • 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: Generate a one-time pad from say a 256bit key?
    ... communications, but as it's a large padfile she'd rather not give it to ... That would only work for a OTP of 256 bits or fewer. ... lovely algorithms which can take a 256 bit key and are considered very ...
    (sci.crypt)