Cryptography-Digest Digest #554, Volume #14 Thu, 7 Jun 01 16:13:00 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: shifts are slow? (Bob Jenkins)
Re: Alice and Bob Speak MooJoo ([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: shifts are slow? ([EMAIL PROTECTED])
Re: MD5 for random number generation? (Tim Tyler)
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: MD5 for random number generation? ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Alice and Bob Speak MooJoo (Janne Tuukkanen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler)
Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat) ("Joseph Ashwood")
new NSA/echelon rant (V.Z. Nuri)
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
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) (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 18:54:57 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: I fail to see how knowing the length of the plaintext reveals any
: information contained within the plaintext.
It lets you rule out plaintexts that were previously possible, and
give them a probability of zero.
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".
: You fail to solve even the most trivial of examples I pose.
Hardly suprising is it? I told you that it was obvious to everyone that
such examples were impossible to solve uniquely. Why do you not tire of
repeatedly presenting them?
--
__________
|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 18:57:10 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> OK - so can you identify one bit in that stream which is *not*
:> significant?
: Everything after the final ``1''.
Which bit is that? You don't know where the final "1" is, if you ignore
some of the bits, now do you? So all bits *are* significant.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 15:06:16 -0400
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> Tim Tyler <[EMAIL PROTECTED]> writes:
>>>
>>> Those points indicate that the chance of getting a false positive in the
>>> system you describe are small.
>>
>> As in, ``you're better off waiting for the sun to burn out and the
>> universe to collapse, than waiting for false positives.'' Yes, correct;
>> I guess you could call that ``small''.
>
> You're wrong too. In an OTP like system, it's not that guessing the
> message is hard or improbable. It's that it's IMPOSSIBLE.
Don't lose track Tom--I wasn't talking about OTP.
I offered a reasonable (though extremely ballpark) estimate of the
likelihood of plausible (or ``false positive'') decryptions when no
compression is used. I then suggested approximately HOW MUCH MORE common
BICOM would have to make the plausible files before it actually translates
into false positive decryptions more often than, say, having our sun
burn out.
The estimate (1) gives strong reasons to doubt that BICOM has *any*
practical benefit, apart from making decryption take a little longer
(and the usual benefits of compression), and (2) gives Tim T. some
idea what he would have to prove, in order to substantiate his claims
for BICOM. ``It's obvious, because there are just lots and lots
of...'' doesn't actually mean diddly.
Are we all together now?
Len.
--
The ``attack'' that Warfield mentions was not a qmail problem; it was
a fraudulent marketing stunt by the Postfix author.
-- Dan Bernstein
------------------------------
From: [EMAIL PROTECTED] (Bob Jenkins)
Subject: Re: shifts are slow?
Date: 7 Jun 2001 12:11:00 -0700
Jeffrey Williams <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Realistically, given the speed of today's processors, and the insanely low
> cost per MIP, MOST OF THE TIME, you'd be better off writing your program in a
> high-level language and using an optimizing compiler which can take full
> advantage of the target processor.
Ciphers are in the part of the time that isn't most of the time. Even
if you're not aiming at a specific chip, it helps to have SOME model of
how much various things cost. "Don't try" isn't an acceptable answer.
Hum. I suppose it's possible that things are so complicated nowadays,
the only reasonable design strategy for a portable cipher is trial and
error, with actual timings on multiple architectures. Are things really
that bad?
(I design hashes for hash table lookup more than real ciphers, but the
issues are the same.)
------------------------------
Subject: Re: Alice and Bob Speak MooJoo
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 15:11:54 -0400
"Robert J. Kolker" <[EMAIL PROTECTED]> writes:
>
> Suppose Alice and Bob share a language
> (herein called MooJoo) which is spoken
> or read by no others.
>
> Then all their plaintexts would be perfectly
> secure. No crypto necessary at all.
>
> Which leads to the question, why hasn't MooJoo
> been invented?
There are two main problems:
1. If the language needs to be ``invented'', then in fact it's no
different than any old-fashioned code: there will be dictionaries
floating around, which can be stolen. The effort of learning the
``language'' is comparable to the effort of memorizing a lengthy
codebook.
2. If the language does NOT need to be invented, it means you're lucky
enough to have allies who speak a nearly-dead language. That's lovely!
But, at the same time, you have key-management problems: putting enough
speakers in the right places; and finding your unit incommunicado if
the code-talker gets shot. Finally, if the enemy manages to kidnap one
of the remaining speakers, say from the 7-11 where she works, then they
have broken your code--and you've wasted an awful lot of time and expense.
Len.
--
We select our marketable equity securities in much the same way we would
evaluate a business for acquisition in its entirety.
-- Warren Buffett, 1977
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 19:12:06 GMT
"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : I fail to see how knowing the length of the plaintext reveals any
> : information contained within the plaintext.
>
> It lets you rule out plaintexts that were previously possible, and
> give them a probability of zero.
>
> 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.
Aside from that. In the set S of remaing plaintexts, how would you know the
right one?
Let's do the # game.
You pick up a 37 byte message.
There are (96)^37 possible ASCII messages thereabouts. That's 2^243. of
the 2^243 possible blocks probably at least 2^100 of those will pass the
most rigourous digraph analysis. Of the 2^100 remaining probably 2^90 are
made up of real english words. Of the 2^90 remaining probably 2^50 of them
have words in the right order. etc...
So we end up with probably around 2^25 or so possible valid sounding
messages.
Sounds bad right? Wrong, it actually doesn't matter!
> : You fail to solve even the most trivial of examples I pose.
>
> Hardly suprising is it? I told you that it was obvious to everyone that
> such examples were impossible to solve uniquely. Why do you not tire of
> repeatedly presenting them?
Because that's what an OTP is. You claim an OTP is not secure yet you can
solve one. Hmm seems like you're a bit confused!
Tom
------------------------------
Subject: Re: shifts are slow?
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 15:17:30 -0400
[EMAIL PROTECTED] (Bob Jenkins) writes:
>
> Hum. I suppose it's possible that things are so complicated nowadays,
> the only reasonable design strategy for a portable cipher is trial and
> error, with actual timings on multiple architectures. Are things really
> that bad?
No. (You're forgetting that the average computer science major has failed
algorithms at least once before finally passing. ``Let the compiler do
it,'' is a religious mantra, repeated by people who have no choice.)
Len.
--
Frugal Tip #52:
Beat up third graders for their lunch money.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: MD5 for random number generation?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 19:17:06 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> 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? [...]
:>
:> The RSAREF PRNG uses MD5, driven by a counter.
: Yeah, you have to make sure though, that your PRNG is forward and backwards
: safe.
: I.e if the output is X X A Y B X X ...
: And you know Y, you shouldn't find B or A with any advantage over the size
: of the blocks.
: This can be done via
: H[i] = HASH(H[i - 1] || SEED || i)
: Where SEED is your initial private seed, i is the counter. You can mix in
: H[i - 1] to get a bit more bits mangled, but in theory you don't have todo
: that. 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.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 15:25:35 -0400
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>>
>> 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.
You're a loon. ;-)
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: MD5 for random number generation?
Date: Thu, 07 Jun 2001 19:29: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]...
> :> 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? [...]
> :>
> :> The RSAREF PRNG uses MD5, driven by a counter.
>
> : Yeah, you have to make sure though, that your PRNG is forward and
backwards
> : safe.
>
> : I.e if the output is X X A Y B X X ...
>
> : And you know Y, you shouldn't find B or A with any advantage over the
size
> : of the blocks.
>
> : This can be done via
>
> : H[i] = HASH(H[i - 1] || SEED || i)
>
> : Where SEED is your initial private seed, i is the counter. You can mix
in
> : H[i - 1] to get a bit more bits mangled, but in theory you don't have
todo
> : that. 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...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 19:30:04 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > "Tim Tyler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >>
> >> 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.
>
> You're a loon. ;-)
Why? If the length is suppose to be hidden there can be no finite length on
the input length. Otherwise it could be known.
Tom
------------------------------
From: Janne Tuukkanen <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 22:14:18 +0300
"Robert J. Kolker" wrote:
> Suppose Alice and Bob share a language
> (herein called MooJoo) which is spoken
> or read by no others.
>
> Then all their plaintexts would be perfectly
> secure. No crypto necessary at all.
>
> Which leads to the question, why hasn't MooJoo
> been invented? It sure would solve a lot of
> problems in private communications;
Niinpä... Mutta kielikin on vain koodijärjestelmä, ja
jos vaikkapaka viitisen miljoonaa suomalaista tuntee
avaimen, niin sekaan mahtuu mustahattujakin. (jotka
pahantahtoisesti voisivat kääntää tämänkin tekstin
vaikkapa lontooksi) Toisaalta avaimen muuttaminen
kesken kaiken on tuskastuttavan hankalaa. Hyvä puoli
on tietenkin kommunikoinnin nopeus ja luontevuus.
Luonnollisessa käytössä olevan kielen 'murtaminen'
(eli opetteleminen vain kuuntelemalla ja katselemalla)
olisi melko helppoa. Eiväthän kielet ole syntyneet
mahdollisimman vaikeasti opittaviksi, pikemminkin päin-
vastoin. Tässä suhteessa salakirjoitus- ja kielitieteen
tutkimuskohteet kyllä eroavat jyrkästi toisistaan.
JanneT
obEnglish: Made Bignum functionality for JavaScript. Can
be found from URL below. RSA key generation or decrypting
can't be called 'fast' ;) but it does m exp e mod n
in reasonable time, with no so many one bits in e...
--
Janne Tuukkanen Fools ignore complexity
[EMAIL PROTECTED] Pragmatists suffer it
Simple Script Security: Some can avoid it
http://projannet.port5.com/ Geniuses remove it - A.J.Perlis
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 19:27:17 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : I fail to see how knowing the length of the plaintext reveals any
:> : information contained within the plaintext.
:>
:> It lets you rule out plaintexts that were previously possible, and
:> give them a probability of zero.
:>
:> 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) - and
it can also be managed if there's only a finite number of possible
plaintexts.
There's nothing about the definition of a cypher that says it must be able
to handle messages of arbitrary length.
[snip]
:> : You fail to solve even the most trivial of examples I pose.
:>
:> Hardly suprising is it? I told you that it was obvious to everyone that
:> such examples were impossible to solve uniquely. Why do you not tire of
:> repeatedly presenting them?
: Because that's what an OTP is. You claim an OTP is not secure yet you can
: solve one. Hmm seems like you're a bit confused!
I claim an OTP which has to deal with messages of differing lengths
doesn't have perfect secrecy.
A rather obvious claim if have the definition of perfect secrecy in
front of you - e.g.:
``The unbreakable strength delivered by a cipher in which all possible
ciphertexts may be key-selected with equal probability given any
possible plaintext. This means that no ciphertext can imply any
particular plaintext any more than any other.''
- http://www.io.com/~ritter/GLOSSARY.HTM#PerfectSecrecy
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA's new Factoring Challenges: $200,000 prize. (my be repeat)
Date: Thu, 7 Jun 2001 12:24:21 -0700
Crossposted-To: sci.math
"Michael Brown" <[EMAIL PROTECTED]> wrote in message
news:VlDT6.707$[EMAIL PROTECTED]...
> <BEGIN REPEAT>
[snip]
> Is this closer to an algorithm?
No it's not. It's pure gibberish, you assumed definitions that simply don't
hold in all computers, let alone all of mathematics (e.g. dword). You assume
it will be implemented on a general purpose computer, you make arbitrary
definitions without foundation (e.g. A,B,O,C), you change the type of
variables (e.g. moving from base 4 to dword). You fail to define even the
most fundamental of algorithms (e.g. the lookup table generation algorithm).
You spontaneously create variables and then depend on them to have specific
values (e.g. HBoxes). You use variable notation when what you wanted was a
function (e.g. GetNextBox). You state simply "Repeat 4 & 5 until you can't
go any further" instead of defining the termination conditions and building
a proper loop. You state that step 5 is constant per box, then state that
there's a maximum of doing each one four times, which one is correct? You
then proceed to make a judgement on the speed without defining your
algorithm in the slightest. Did you even read my last message? Did you
notice the (incomplete, but specific) example of an algorithm? Can you
manage to express your gibberish simularly?
Joe
------------------------------
From: [EMAIL PROTECTED] (V.Z. Nuri)
Subject: new NSA/echelon rant
Date: Thu, 7 Jun 2001 19:37:59 +0000 (UTC)
can echelon be exposed? can it be trounced?
I'm looking for any old article by someone who
lambastes the idea of a global data collection
system as impossible, infeasible, etc. the more
credible the author/outlet, the better. ideally
a smug op-ed piece in some uptight mainstream
newspaper etcetera.
the idea is to get the most closeminded denunciation
of the idea possible to show it in contrast with
new information about echelon/carnivore/CIA
datamining capabilities. useful propaganda.
for your amusement.
a fresh rant on the NSA, their role in blocking
the RSA patent, and echelon.. and the idea
of CIA datamining/carnivore press info as diversionary
tactics.
http://groups.yahoo.com/group/theory-edge/message/3180
stop by theory-edge if you want to talk about
hard-core algorithms or mathematics. its
a pretty civil environment.
http://groups.yahoo.com/group/theory-edge/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
--
Posted from web12208.mail.yahoo.com [216.136.173.92]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Thu, 07 Jun 2001 19:39:56 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:
>
> :> : I fail to see how knowing the length of the plaintext reveals any
> :> : information contained within the plaintext.
> :>
> :> It lets you rule out plaintexts that were previously possible, and
> :> give them a probability of zero.
> :>
> :> 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) - and
> it can also be managed if there's only a finite number of possible
> plaintexts.
Um a stream cipher cannot encrypt an infinite length plaintext without
infinite memory. (Fact of math)
> There's nothing about the definition of a cypher that says it must be able
> to handle messages of arbitrary length.
This is so meaningless I can't cope. A cipher is not formally defined to be
anything. It's technically a jargon word we use in place of a series of
ideas that encapsulate what we think of as a cipher.
> :> : You fail to solve even the most trivial of examples I pose.
> :>
> :> Hardly suprising is it? I told you that it was obvious to everyone
that
> :> such examples were impossible to solve uniquely. Why do you not tire
of
> :> repeatedly presenting them?
>
> : Because that's what an OTP is. You claim an OTP is not secure yet you
can
> : solve one. Hmm seems like you're a bit confused!
>
> I claim an OTP which has to deal with messages of differing lengths
> doesn't have perfect secrecy.
>
> A rather obvious claim if have the definition of perfect secrecy in
> front of you - e.g.:
>
> ``The unbreakable strength delivered by a cipher in which all possible
> ciphertexts may be key-selected with equal probability given any
> possible plaintext. This means that no ciphertext can imply any
> particular plaintext any more than any other.''
>
> - http://www.io.com/~ritter/GLOSSARY.HTM#PerfectSecrecy
I fail to see "particular plaintext of an infinite domain".
What I don't get is even BICOM (which you support) cannot supply this
property either!
Tom
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 7 Jun 2001 19:45:39 GMT
[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''. Since in
: English ``generally greater'' permits ``possibly equal'', I'll give it
: to you. But with that proviso, you've actually said nothing of interest.
I have previously said that they will sometimes be greater, sometimes
equal and sometimes less frequent. However, the net effect is that they
will be more frequent.
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.
If you can't get a grasp on the situation from this, I think there's
probably no hope for you.
:> I also claim that there are systems where the chances of collisions
:> arising are high.
: Generally, those are the same systems in which OTP is the obvious way to
: go.
Not really. All that is necessary for collisions to occur is that /some/
messages approach the size of the key after compression.
The system can happily include some multi-megabyte files - where using an
OTP would not be a practical proposition.
:> Yes there are systems where the chances of collisions are low - so what?
: So what? Specifically: *THE* system I've described above is *THE*
: system w.r.t. which you claim BICOM provides a genuine increase in
: secrecy--namely, English messages up to 1K in size.
Compression increases the chance of message collisions regardless of
the size of the message. However the absolute chance of
collisions may well be low for large messages.
Where did I previously mention messages of 1K in size? Can you quote
me doing so?
:> : Your problem boils down to this: you haven't the faintest idea what
:> : ``lots'' means--and in the three uses above, ``lots'' varies by
:> : thousands of orders of magnitude.
:>
:> Compression increases the chances of trial decrypts producing plausible
:> messages by increasing the unicity distance of the overall system.
: From 1/2^15000 to 1/2^12000?
For some plaintexts, yes.
: Even if true, so the heck what?
In that case the improvement may be of little practical consequence.
: You need to prove that it increases the chances of false positives by
: enough to *actually matter* [...]
Which it /does/ for shorter messages.
: Not only haven't you done so, you aren't ever going to either.
Did you miss my 129 bit message? Say it was 256 bits before compression.
What then?
: 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.
I recommend you back down now before you make an even bigger fool out of
yourself.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 07 Jun 2001 19:50:37 GMT
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
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. :-)
You posted an example where you thought it was obvious that a two-character
encrypted response meant "no," and three letters meant "yes." I pointed out
that it isn't neccesarily so. You might as well flip a coin.
>Where would your objection be if the word for the affirmative had seven
>letters?
Off hand, I'd say if you were the attacker, you'd be confused! :-)
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 7 Jun 2001 19:43:06 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>: Since if they were you would think Wagner who at least pretends to know
>: something about crypto would set them straight. Why he does not bother
>: to make an honest useful comment on a thread like this makes
>: me wonder just how much he wants the average person to know
>: about crypto. He could help people like TOMMY on these concepts
>: but refuses any useful real help. WHY??
>
>Most of the time I'm on David Wagner's fan list. He has personally
>set me straight or offered me assistance on a number of occasions.
>
>I don't think you can take a lack of usenet posts as evidence of bad
>character. Generally I'm happy that he visits sci.crypt at all.
Well at least people can see we diagress on certain issuses.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
** 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
******************************
