Cryptography-Digest Digest #556, Volume #14 Thu, 7 Jun 01 18:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: MD5 for random number generation? (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Re: Brute-forcing RC4 ("Joseph Ashwood")
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (JPeschel)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Brute-forcing RC4 (Ichinin)
Any Informed Opinions? ("Robert J. Kolker")
Re: Alice and Bob Speak MooJoo (Ichinin)
Re: MD5 for random number generation? ("Tom St Denis")
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
----------------------------------------------------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 16:48:45 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>: Tim Tyler <[EMAIL PROTECTED]> writes:
>:
>:> My claim is that the chances of collisions are generally greater if
>:> compression has been employed than if not.
>:
>: You are wrong to say ``generally greater''; you have not proven that
>: they actually are greater. You can only say they are ``no less''.
>
> ...the net effect is that they will be more frequent.
You don't have any idea what the net effect will be. In fact, I gave a
fairly thorough explanation why the net effect is almost certainly no
such thing. You need to *prove* that the ``net effect'' will be what
you say.
> If you have a fishtank and all the fish swim towards one end, the
> chances of finding fish at that end will be generally greater.
> Sometimes if you look by the castle you will find greater, fewer or
> an equal number of fish in its neighbourhood - but *on average* the
> density of fish at that end of the tank will be greater.
> The fish are plausible plaintexts. The tank represents files
> sorted by size. Files at the end of the tank are shorter than ones
> further away. The directional swimming of the fish represents
> compression.
GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
submit it to the Acta Mathematica, will you? You must be Isaac Newton
reborn!
Question: If there are 50 billion billion eels, and 2000 guppies, and
they all start in one end of the tank--which is 45,000 light-years long,
when can I expect to catch a guppy at the far end of the tank?
Translation: You keep using words like ``some'' or ``a lot'' or
``greater than'' or ``better'' without any attempt whatsoever to
verify that the hypothetical ``improvement'' will *ever* affect an
attacker.
> Did you miss my 129 bit message?
If that's not the only message you send, then we're NOT dealing with
only 129 bits; we're dealing with all the bits you encrypted with that
key. On the other hand, if you DID send only 129 bits with a 128-bit
key, and then throw the key away--but DIDN'T use a one-time pad, then
you're an idiot.
>: Bottom line: ``All BICOM gives you, assuming its correctness, is an
>: increase in the work required to brute-force the key.''
>
> If that's your bottom line then I have to say your panties are showing.
Didn't you used to date Ludwig Plutonium?
Len.
--
Performance speculation is bad. Performance hypocrisy is much worse.
-- Dan Bernstein
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 20:44:35 GMT
John Myre <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> I see. You think you know better how to explain how Matt Timmermans
:> compressor operates than Matt Timmermans himself.
: Where does that come from?
http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
: On the whole, Len's posts are more convincing to me than
: yours are. [...]
Well, this isn't a popularity contest - this is a scientific forum.
Is there anything specific you don't agree with?
: He may be wrong, but he's not an idiot. [...]
I don't believe I've called him an idiot to date.
He has some technical knowledge - but he has now made rather a lot of
mistakes. Entropy, perfect secrecy, compression - he seems to have an
innacurate view about everything :-|
The posts of his that /really/ rub me up the wrong way are the ones where
he misquotes me - or where he snipped what I wrote, apparently in order to
distort it.
If he could stop doing things like that the debate would go much more
smoothly.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: MD5 for random number generation?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 20:53:24 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> Toby Sharp wrote:
:> :> > I've heard of people using MD5 for random number generation. But, as
:> :> > far as I can tell, MD5 is a one-way hash algorithm. How is this
:> :> > used for random numbers? [...]
:> : Yeah, you have to make sure though, that your PRNG is forward and
:> : backwards safe. [...]
:> So you could just use
:>
:> : H[i] = HASH(SEED || i)
:>
:> : Which is essentially a CTR mode of operation.
:>
:> It looks like you're thinking of state compromises that don't affect SEED.
:>
:> If you think SEED might also be compromised, backward secrecy is
:> hardly possible (without a source of entropy anyway) - and the
:> second equation offers no forward secrecy.
: Here's a tip. Give some thought to what you post.
: No PRNG is ever secure if the initial seed is compromised. The seed is what
: determines the PRNG output...
Security in the face of state compromise is a very important part of
what forward secrecy in RNGs is all about.
As for backward secrecy - this is (as I mentioned) impossible in a PRNG
whose state has been compromised. However, the OP never mentioned PRNGs.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 20:59:07 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Shannon proved an OTP was secure - *if* all the messages were half
:> infinite streams.
: "half infinite streams"? That's meaningless. You can take half of oo since
: oo/2 = oo.
Your math background really isn't very good is it?
Have a look at: http://google.com/search?q="half-infinite";
...and come back if you still don't know what half-infinite means.
: An OTP as far as I am concerned is defined by
: 1. Message is as long as key.
: 2. Each bit of key is used once, mixed with some invertable operation to
: form the ciphertext.
: I never really see the need for "infinite length text" for an OTP to be
: secure.
Me neither - all messages the same length would be perfectly good enough.
: Perhaps if you defined your threat model this would make sense. Why in your
: world is knowing the length of the message a threat?
See David's "Yes"/"No" example.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 23:06:11 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : Tim Tyler wrote:
> :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> :> : Tim Tyler wrote:
>
> :> :> Traffic analysis information is indeed often present -
> :> :> but we are talking about once a message exists, does
> :> :> the attacker gain anything by looking at the cyphertext.
> :> :>
> :> :> That's what the definition of "perfect secrecy" talks about.
> :> :>
> :> :> Perfect secrecy applies to encryption devices. Time of
> :> :> message transmission etc is considered to be outside its scope.
> :> :>
> :> :> A conventional OTP, [...] does not
> :> :> have Shannon's perfect secrecy property.
> :>
> :> : I am not of the opinion that size is 'inherently' different
> :> : from time etc. in the present context.
> :>
> :> Well, you should be. Length is a property that can be used to
> :> distingush between elements of the set of possible plaintexts -
> :> while time cannot be so used.
>
> : Why not?
>
> Shannon's definition relates to the state of the attacker before and
> after knowledge of the *cyphertext* - not the cyphertext and a whole
> bunch of other information from traffic analysis.
>
> It's a property of a cyphertext/plaintext translator - and is
> normally independent of the time the message is sent.
>
> : I could well agree with my partner that if a mail
> : (of any innocent content) is sent between 9 and
> : 10 o'clock it means one thing while between 10 and 11
> : o'clock it means the opposite. At least one bit can
> : be transmitted that way. (More could be done by
> : more sophisticated agreement.)
>
> So, how do you think that fits into Shannon's definition of perfect
> secrecy? In partcular, what is the cyphertext?
>
> ISTM that your arrangement (from the point of view of Shannon's
> definition) just complicates the question of what constitutes the
> cyphertext of the message.
>
> If you can identify the cyphertext, the definition of perfect secrecy
> can again be applied.
The ciphertext would be the time attached to the mail.
If the time falls in one interval, it represents the
0-bit, if in the other interval, it represents the
1-bit. It is just a rather unconventional code,
though very uneconomical.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 07 Jun 2001 21:11:00 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Tim Tyler [EMAIL PROTECTED] writes:
>JPeschel <[EMAIL PROTECTED]> wrote:
>
>: I could try to make the case that since I have some ciphertext, I know
>: some information about the plaintext: That it actually exists! But I'd be
>: kidding around. :-)
>
>The definition of perfect secrecy could be reformulated to
>cope with null cyphertexts if that was considered necessary.
>
Now don't start re-defining again! (Yeah, I know you don't think you've
re-defined anthing.)
>In practice, it would probably be a bad idea to do this, most of the time.
>
Ya.
>At the moment the definition asks how much information is gained by the
>attacker by observation of the cyphertext.
>
>Allowing null cyphertexts might be desirable under some circumstances -for
>example if you can guarantee message delivery - since the additional
>message state does indeed offer the opportunity of improving secrecy.
Even if you enciphered null or random plaintext, you still know, upon looking
at the ciphertext that a plaintext existed. This, of course, gives you nothing
useful to attack the cipher, but neither does know the message length. :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Thu, 7 Jun 2001 12:41:38 -0700
There was a mention a year and a half ago on this group of using a small
beowolf cluster of overclocked celerons (at the time this would bring it to
approximately the 500MHz mark), and being able to brute force RC4-40 in a
few days for $1200, with proper optimization I think it could be lowered.
Let's see
Load takes L1 clocks
Store takes S1 clocks
In each iteration of the key schedule there are 3 loads, and 2 stores. the 2
of the 3 loads can be done simultaneously, and parellelized highly, so the
throughput there can be reduced to say 1.5 cache clocks per value. The
stores are fully async on modern cpus, so those will take only 1 clock each.
You've got about 6.5 clocks for each iteration of the RC4 key schedule.
There are 256 iterations for the entire key schedule so that's 1664 clocks
for initialization. RC4 can generate a byte in 4 clocks so we'll just assume
that, the likelihood of having to go beyond 2 bytes is negligible and
certainly doesn't compare to the key setup, so we'll pretend we only have to
generate 2 bytes, that's 8 clocks. The value for comparison can be stored in
a register so we don't have to load it, RC4 output will be to a register, so
we simply compare them, that's an additional 1 clock. So we've got a total
of 1664+8+1 clocks for each key. That's 1673 clocks, or 299,000/sec, 3.6
million seconds per key (worst case), that's 42 days. Normally it would
finish in 21 days, 3 systems could be parrelellized on this to finish in a
week on average. This is assuming a very carefully optimized RC4
implementation by someone who is exceptionally good at writing assembly,
with a reasonable assembly coder, you're looking at twice as long, minimum,
and a compiler using pure C would probably offer better results.
Joe
"S Degen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> depending on the processor-speed, but lets say a PIII 500)
>
> This is the case:
> You have a 128 bit (ASCII) text, and the encyphered version of it. This
> version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> bits are known. (Leaving 40 unkown bits)
>
> I would like to know how long it would approximately take to calculate
> the 40 bit secret key.
>
> (Worst case scenario)
>
>
> Thank you if you can help me.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 21:07:04 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
: news:[EMAIL PROTECTED]...
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
:> :> :> Shannon states that for perfect secrecy the cyphertext must not
:> :> :> give *any* clues to the plaintext.
:> :> :>
:> :> :> Not "no clues apart from the length", but "no clues at all".
:> :>
:> :> : Yes, but you cannot invent a cipher to avoid this. You would need an
:> :> : infinite length plaintext.
:> :>
:> :> A stream cypher can manage it (infinite plaintext as you say) [...]
:>
:> : Um a stream cipher cannot encrypt an infinite length plaintext without
:> : infinite memory. (Fact of math)
:>
:> Well, strictly speaking it seems likely that nothing can encrypt an
:> infinite plaintext because the universe will burn out while it tries.
:>
:> That aside, memory does not stop stream cyphers from encrypting large
:> messages, since the stream doe snot need to be stored all at once.
:> Why would you think otherwise?
: Because a finite state machine can only be in a finite number of states.
Why do you need to have more than a million states to act as a stream
cypher on long messages?
: Think about it. You have a private state for a PRNG of size X bits. Where
: X < oo. This means the PRNG can be in at most 2^X states. Where 2^X < oo
: as well. Hence....
Hence...what?
Sure - *if* the stream cypher happens to be one that doesn't interact with
the message, the stream will repeat after a while - but that won't
actually prevent encyphering the plaintext, will it?
: Yes, but my problem is perhaps you're right and knowing the length is a
: fault of PERFECT secrecy. So what... Who cares?
I care for one. It is important if many people are under the delusion
that the OTP provides perfect secrecy - when in fact it does not do so
in the configurations in which it is commonly used.
: I don't see alot of academia calling for "length hiding transforms" [...]
It's usually referred to as "padding".
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 07 Jun 2001 21:16:29 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
"Tom St Denis" [EMAIL PROTECTED] writes, in part:
>Cipher, despite what you want to think, is not a real english or
>mathematical word. It's slang.
Sorry, guy. It's not slang, it's real English. When Tim spells
it "cypher" he is using the British spelling.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 21:11:10 GMT
JPeschel <[EMAIL PROTECTED]> wrote:
: Tim Tyler [EMAIL PROTECTED] writes, in part:
:>If you nitpick the examples without actually attacking the basic point,
:>we will only find other ones.
: Tim, "we" appears to only you and maybe Dave. :-)
I was using the royal we ;-)
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Brute-forcing RC4
Date: Wed, 06 Jun 2001 09:41:11 +0200
Scott Fluhrer wrote:
>
> Ichinin <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hi.
> >
> > S Degen wrote:
> > >
> > > Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> > > depending on the processor-speed, but lets say a PIII 500)
> >
> > Don't really know about a P3/500, but compare
> >
> > In my home lab i did a brute force estimate once on RC4
> > (including all key setups and guessing).
> >
> > Using:
> >
> > 1 x P1/133 acting as a job server
> > 1 x P2/266 - slave client
> > 1 x AMD K6/350 - slave client
> > 1 x P3/700 (Bus can be clocked to 117 Mhz; == ~819 Mhz)
> >
> > ..i estimated that with a C++ plugin for each slave
> > client, i could brute force a 2^40 key in roughly 180
> > days.
> >
> > The computing power could be compared to 2 to 2.5 P3/500,
> > so, if my guess is correct, around 180 x 2 (or 2.5) days.
>
> I haven't actually run any expirements, but that doesn't sound right to me.
> An iteration of the RC4 key setup takes 7 operations by my count (counting
> loads/stores/adds-mod-256 as one operation), and is somewhat parallizable.
> It happens 256 times for each key, and then there are a few operations to
> generate the first byte of keystream, test it, and then step to the next
> key. All this (because of the parallizability) should be quite doable in
> 7*256 cycles or 3.5usec, and possibily half that. A complete keysearch
> should then take 3.5 * 2^40 = 4 * 10^12 usec = 44 days, with the expected
> time being half that.
>
> Were you using any fancy C++ classes in the key setup? That'd get in the
> way.
Nope, a vanilla RC4 implementation in VC++.
Could be the checking algorithm; i.e. step
through the decrypted message; is it alpha
numerical only?
I'll look it over, thanks.
.Reg's,
Ichinin
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Any Informed Opinions?
Date: Thu, 07 Jun 2001 17:22:44 -0400
Does anyone have informed opinions
on what influence quantum computing
will have on cryptography and
cryptanalysis?
Qbits are alive and real. It remains to
be seen if genuine computers can be
made from them.
Bob Kolker
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Alice and Bob Speak MooJoo
Date: Wed, 06 Jun 2001 09:45:05 +0200
Janne Tuukkanen wrote:
<Suomalainen stuff deleted>
Finnish isn't an unknown language. However, the US Navy utilised
navaho during ww2; http://www.nsa.gov:8080/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: MD5 for random number generation?
Date: Thu, 07 Jun 2001 21:27:28 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> :> Toby Sharp wrote:
>
> :> :> > I've heard of people using MD5 for random number generation. But,
as
> :> :> > far as I can tell, MD5 is a one-way hash algorithm. How is this
> :> :> > used for random numbers? [...]
>
> :> : Yeah, you have to make sure though, that your PRNG is forward and
> :> : backwards safe. [...]
>
> :> So you could just use
> :>
> :> : H[i] = HASH(SEED || i)
> :>
> :> : Which is essentially a CTR mode of operation.
> :>
> :> It looks like you're thinking of state compromises that don't affect
SEED.
> :>
> :> If you think SEED might also be compromised, backward secrecy is
> :> hardly possible (without a source of entropy anyway) - and the
> :> second equation offers no forward secrecy.
>
> : Here's a tip. Give some thought to what you post.
>
> : No PRNG is ever secure if the initial seed is compromised. The seed is
what
> : determines the PRNG output...
>
> Security in the face of state compromise is a very important part of
> what forward secrecy in RNGs is all about.
Yes. And my PRNG I proposed is forward secure.
H[i] = HASH(SEED || I)
Suppose you guess H[i], how do you get H[i+1] or H[i-1]?
If you guess SEED this PRNG is not secure which is why I stated re-seeding
is important.
> As for backward secrecy - this is (as I mentioned) impossible in a PRNG
> whose state has been compromised. However, the OP never mentioned PRNGs.
Are you sure? Read the subject line!
Tom
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 17:29:13 -0400
Ichinin wrote:
> Janne Tuukkanen wrote:
> <Suomalainen stuff deleted>
>
> Finnish isn't an unknown language. However, the US Navy utilised
> navaho during ww2; http://www.nsa.gov:8080/
And I thought it was Elvish, straight out of Lord of the Rings.
Maybe the Finns are Elven folk after all.
My apologies.
Bob Kolker
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 21:30:27 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> :> Shannon proved an OTP was secure - *if* all the messages were half
> :> infinite streams.
>
> : "half infinite streams"? That's meaningless. You can take half of oo
since
> : oo/2 = oo.
>
> Your math background really isn't very good is it?
>
> Have a look at: http://google.com/search?q="half-infinite";
>
> ...and come back if you still don't know what half-infinite means.
>
> : An OTP as far as I am concerned is defined by
>
> : 1. Message is as long as key.
> : 2. Each bit of key is used once, mixed with some invertable operation
to
> : form the ciphertext.
>
> : I never really see the need for "infinite length text" for an OTP to be
> : secure.
>
> Me neither - all messages the same length would be perfectly good enough.
>
> : Perhaps if you defined your threat model this would make sense. Why in
your
> : world is knowing the length of the message a threat?
>
> See David's "Yes"/"No" example.
What 1/0?
Obviously this is a contrived example. I could just as easily say with 1/0
if 1 has p=0.99 then we can solve the system even if an OTP is used...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 21:32:17 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
> : news:[EMAIL PROTECTED]...
> :> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> :> : "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
>
> :> :> :> Shannon states that for perfect secrecy the cyphertext must not
> :> :> :> give *any* clues to the plaintext.
> :> :> :>
> :> :> :> Not "no clues apart from the length", but "no clues at all".
> :> :>
> :> :> : Yes, but you cannot invent a cipher to avoid this. You would need
an
> :> :> : infinite length plaintext.
> :> :>
> :> :> A stream cypher can manage it (infinite plaintext as you say) [...]
> :>
> :> : Um a stream cipher cannot encrypt an infinite length plaintext
without
> :> : infinite memory. (Fact of math)
> :>
> :> Well, strictly speaking it seems likely that nothing can encrypt an
> :> infinite plaintext because the universe will burn out while it tries.
> :>
> :> That aside, memory does not stop stream cyphers from encrypting large
> :> messages, since the stream doe snot need to be stored all at once.
> :> Why would you think otherwise?
>
> : Because a finite state machine can only be in a finite number of states.
>
> Why do you need to have more than a million states to act as a stream
> cypher on long messages?
If you reuse the PRNG output (replace PRNG with stream cipher if you will)
then you're looking for trouble.
> : Think about it. You have a private state for a PRNG of size X bits.
Where
> : X < oo. This means the PRNG can be in at most 2^X states. Where 2^X <
oo
> : as well. Hence....
>
> Hence...what?
>
> Sure - *if* the stream cypher happens to be one that doesn't interact with
> the message, the stream will repeat after a while - but that won't
> actually prevent encyphering the plaintext, will it?
But it won't be secure. It will be just like re-using the OTP pad.
> : Yes, but my problem is perhaps you're right and knowing the length is a
> : fault of PERFECT secrecy. So what... Who cares?
>
> I care for one. It is important if many people are under the delusion
> that the OTP provides perfect secrecy - when in fact it does not do so
> in the configurations in which it is commonly used.
>
> : I don't see alot of academia calling for "length hiding transforms"
[...]
>
> It's usually referred to as "padding".
Even as that.
WHAT GOOD DOES IT PROVIDE!!!!!!!!11
[sound of human screaming]
If you can't tell the contents what does the length provide?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 21:33:13 GMT
"JPeschel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" [EMAIL PROTECTED] writes, in part:
>
> >Cipher, despite what you want to think, is not a real english or
> >mathematical word. It's slang.
>
> Sorry, guy. It's not slang, it's real English. When Tim spells
> it "cypher" he is using the British spelling.
I wouldn't consider cipher as formal english. It sounds to "The Net"ish.
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
