Cryptography-Digest Digest #144, Volume #9 Fri, 26 Feb 99 01:13:05 EST
Contents:
Re: Testing Algorithms [moving off-topic] (Doggmatic)
Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness Come
From ?!? *** ) (R. Knauer)
Re: A New Public-Key Cryptosystem ([EMAIL PROTECTED])
Re: A New Public-Key Cryptosystem ([EMAIL PROTECTED])
Re: Testing Algorithms (Darren New)
Re: Another extension to CipherSaber (Darren New)
Re: Define Randomness (Darren New)
Re: RC4 40 bit compared to RC4 128 bit. (Doug Stell)
Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
([EMAIL PROTECTED])
Re: Define Randomness (R. Knauer)
Re: Define Randomness ("Trevor Jackson, III")
Re: Define Randomness ("Trevor Jackson, III")
Re: Another extension to CipherSaber (Paul Rubin)
----------------------------------------------------------------------------
From: Doggmatic <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms [moving off-topic]
Date: Fri, 26 Feb 1999 04:05:08 GMT
In article <7b101l$q4v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> In article <7avprg$jvm$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>
> The fundamental limit of powering a computer processor is *ZERO*.
>
> Power provides *NO* limitation on how big you can make a computer.
>
> -kitten
Uhh.... who told you that lie? Any process (the smallest possible relevent
one of which is counting) requires a discrete (more than zero) amount of
energy. So, unless your processor does *ZERO* work, it will consume more
than ZERO energy. So, unless this computer is processing in another universe
which is not subject to the physical of this one, there IS a limit.
___/Mike ...two legs good, four legs bad? ... Why conform?
__/. | For my next trick, WATCH as this humble mouse breaks
\-__ \___ Windows at the mere press of a button.
\ Hey! Where are we going, and why am I in this handbasket?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Crossposted-To:
sci.skeptic,sci.philosophy.meta,sci.psychology.theory,alt.hypnosis,sci.logic
Subject: Re: Randomness based consciousness?. (Was: Re: *** Where Does The Randomness
Come From ?!? *** )
Date: Thu, 25 Feb 1999 14:18:47 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 24 Feb 1999 22:12:52 -0600, "Alex Avila" <[EMAIL PROTECTED]>
wrote:
>It seems to me that your argument begs the question.
>It fails to provide a truly cogent reason for actual existence.
>Your premise that things exist becase "you exist" presupposes
>your conclusions that things exist.
I never said that my existence was the reason for why things exist.
I said that you cannot deny existence once you exist.
>Do not listen to this man's fallacious circular reasoning.
Do not listen to this person's sophistry. Existential Metaphysics
takes years of study, which is obviously lacking in this poster's
makeup.
Bob Knauer
"Democracy is the theory that the common people know what they
want, and deserve to get it good and hard."
--H.L. Mencken
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A New Public-Key Cryptosystem
Date: Fri, 26 Feb 1999 04:44:05 GMT
[EMAIL PROTECTED] (John Savard) wrote:
> But the Hill cipher is just matrix multiplication mod 26, so *it* is
> no big deal.
The modulus must be prime, so 26 is out. Prime powers are available, if
one is willing to turn to a Galois field. In the end its all the same
because:
> I remember trying to make a public-key cipher out of the Hill cipher,
> but my attempt didn't work, because matrices can be diagonalized.
... the power of abstract algebra at work.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A New Public-Key Cryptosystem
Date: Fri, 26 Feb 1999 04:47:37 GMT
[EMAIL PROTECTED] (Lowball61) wrote:
> How can a rectanglar matrix be put in a diagonalized form that is useful
> in the sense that somehow an inverse-like operation can be preformed?
Singular value decomposition.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: Fri, 26 Feb 1999 05:02:01 GMT
> What I meant to say was that computing power at the time was
> insufficient for a brute-force crack to be viable, rather than any
> implication that DES was claimed to be unbreakable forever.
Well, of course it's viable, no matter how weak your computer is. You
could crack a DES key on a single Apple-II, if you wanted to wait long
enough. With a 256-bit key, you can't brute-force it no matter how fast
your computers run, quantum computing tentatively excluded.
The point is that people knew a maximum useful lifetime for
DES-encrypted data when it was created. Nobody knows a maximum useful
lifetime for many of the other cyphers, but hope it is longer than
anyone could possible want to spend.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"Be.... the email."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Another extension to CipherSaber
Date: Fri, 26 Feb 1999 05:05:54 GMT
> Or, use a custom utility that works specifically with it. Opting for
> simplicity is a fair choice in any program. Afterall, the noise we here
> from government is far from calling for simplification of implemention,
> just simplification in their confronting it in transmissions.
Actually, I was confused in an earlier private-email thread too. The
idea behind ciphersaber is to create an encryption algorithm and data
format so simple that most every programmer can implement it themself.
Hence, the simplicity of the armoring *is* important. It's not research
into new algorithms.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"Be.... the email."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
Date: Fri, 26 Feb 1999 04:35:46 GMT
> We *can* select the best cipher - the OTP. And we can select the best
> TRNG - a radioactive decay TRNG.
How about photon polarization? Would measuring the angle of polarization
of photons (from a non-polarized source of course) yield the same level
of randomness as measuring radioactive decay times?
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"Be.... the email."
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RC4 40 bit compared to RC4 128 bit.
Date: Thu, 25 Feb 1999 14:19:54 GMT
On Thu, 25 Feb 1999 14:10:15 +1300, "Rats" <[EMAIL PROTECTED]>
wrote:
>However what puzzles me is the referrence sometimes used to describe RC4
>i.e. RC4 40 bit and 128bit. What I don't understand is the relevance of the
>bit values since the algorithm itself doesn't seem to make any mention of
>it.
RC4 is frequenstly called a "variable key length cipher." The way it
does this is as follows. The key length for RC4 is always 256 octets,
2048 bits. If the algorithm's key prep routine is supplied a shorter
key, it simply inputs it multiple times, until it has 256 octets.
Therefore, it can accept any input, up to 256 octets.
40 versus 128 bit RC4 refers to the number of bits of key that are
*secret*. The lower limit was imposed by the US export regulations,
although the limit, I believe, is now 56 bits.
Addition key is normally supplied, but made public in the protocol.
This randomly generated key, called salt, serves the purpose of making
a dictionary attack against 40 bits more difficult.
The secret key and public salt can be combined in any way you wish, as
long as both parties agree on the method. (The US Government initially
wanted simple concatenation.) SSL performs an MD5 hash on the
concatenation of the two. Thus RC4 is always supplied with 128 bits of
key, which it uses 16 times. (If the 160-bit SHA-1 were to be used as
the hash, RC4 would input the 160 bits 12 full times and one partial
time.)
To answer your question, the RC4 algorithms knows nothing about 40
versus 128 bit keys. This is a protocol issue outside of the
algorithm. In fact, it can be and is applied to other algorithms
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unicity of English, was Re: New high-security 56-bit DES: Less-DES
Date: Thu, 25 Feb 1999 14:41:51 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote:
> >
...
> > "Equivocation" (better, conditional entropy) applies not only to the key but
> > also to the message -- two different and quite independent concepts, which
> > of course do not have to be zero at the same length of received text
> > (otherwise, they would be dependent in that sense).
>
> Different yes, independent no. See Shannon's theorem 7.
>
Next, with the same line of "reasoning" you would certainly tell me that time
and distance are dependent since in the special case of uniform motion, s =
s0 + v*t.
But I will not repeat the formulas here, since I already noted that famous
misprint in Shannon's 1949 paper (correct in his 1948 paper) which I thought
might be misleading you in good faith. So, I do not need to argue -- just list
the two conditional entropy formulas and look at them.
> Note pages 693, 696 and 697. When Shannon talks about
> the message equivocation curve, he is considering the
> equivocation corresponding to the intercepted letters.
>
> > You must also change the
> > wording from "no key" to "one key of unity probability"
>
> Fine.
>
> > > This is the
> > > "degenerate type of secrecy system" described by Shannon at the
> > > bottom of page 663.
> >
> > As I quoted, yes. As you quoted, no.
>
> So if I grant that we describe unencrypted plaintext as having
> a key space of one key rather than not having a key, then we're
> in agreement? Granted.
you say "granted" -- but then you immediately *deny* the consequence! Read:
...
> > > without intercepting any ciphertext, yielding a unicity
> > > distance of zero.
> >
> > Non sequitur. Without intercepting any character, the message's conditional
> > entropy is not zero.
...
> > Oh, but why, you may ask. Well, I would suggest you simply write down the
> > formula!!! As often said, surprise and information are synonymous ;-)
>
> The formula for the random cipher? H(k) is zero, and D, the
> [snip, wrong]
OF COURSE NOT! How can you have a random cipher with only one key "granted"?
There is no randomness below two choices, Bryan.
You need to use the conditional message entropy formula, what else? Note, I
even wrote it explicitly, above:
"Non sequitur. Without intercepting any character, the message's conditional
entropy is not zero."
... which you then disagree by using a unicity formula for a random cipher...
which is *not* granted since there is just one key with unity probability.
> I am not surprised.
>From your past msgs, me neither -- unfortunately, I must say. BTW, this points
out that "granted" is not just a discussion stopper -- it is an attitude. And,
one that demands integrity.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Define Randomness
Date: Thu, 25 Feb 1999 15:03:52 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 24 Feb 1999 23:05:42 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>But, I do not trust algorithmic post processing. You will have to
>>convince me that anti-skewing does not introduce unwanted correlations
>>which can wreck the security of the TRNG significantly.
>Can we run a TRNG without post-processing? That would be one
>alternative, but I doubt it is viable.
Hey, I'm the one asking the questions around here! :-)
I think you can build a TRNG that can be used to make crypto-grade
ciphers that leak only an insignificant amount of information in a
given environment. This is equivalent to making a wheel that is
sufficiently circular for a given use.
In fact if you plan to sent only one message that is very small, you
probably could use a text cipher, since it would not leak enough
information to be decipherable.
>And if not, exactly what sort of post-processing would you say is
>*not* algorithmic?
I believe that the very term "processing" implies some kind of
algorithmic procedure.
Bob Knauer
"Democracy is the theory that the common people know what they
want, and deserve to get it good and hard."
--H.L. Mencken
------------------------------
Date: Fri, 26 Feb 1999 00:36:17 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
R. Knauer wrote:
> On Thu, 25 Feb 1999 15:02:34 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >> No. Each pair is operated upon independently, so the actions of one
> >> pair cannot affect the actions of any other pair. The input sequence
> >> to the von Neumann transformation is assumed correlation-free, and
> >> the transformation is stateless so it cannot introduce any correlations.
>
> >Case closed. NEXT!
>
> You are far too quick to jump to conclusions until the issue has been
> completely explored. Is that because you do not want someone
> challenging your pat notions about crypto?
No. I'm bored by an impenetrably stupid audience.
> For one thing, the assumption that the sequence is correlation-free is
> unfounded for an actual sequence, especially one that has noticable
> bias. It is possible that the mechanism that is producing the bias
> could also be producing some kind of long-range correlation that
> becomes short-range correlation when bits are removed by the vN
> procedure.
I've addressed these topics three times. I have failed to communicate the
issues involved three times. Is there any reason for either of us to believe I
might be successful the fourth time?
------------------------------
Date: Fri, 26 Feb 1999 00:40:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
John Savard wrote:
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote, in part:
>
> >We would all probably agree that the Keno games in Reno or Lake Tahoe or
> >Las Vegas, Nevada, produce the twenty numbers used in the game at
> >random, by encasing eighty uniquely numbered ping pong balls in that
> >plastic sphere and driving them into a tumult with a continuous stream
> >of modestly compressed air.
>
> >We would agree to the randomness of the process in part because the
> >outcomes are essentially non reproducible. Furthermore, we would agree
> >to the randomness of the process because the outcome generally over long
> >but modest runs would certainly demonstrate that each numbered ball has
> >the same probability of being among the twenty chosen.
>
> >But we do not have a perfect Keno machine, or perfect information, or a
> >sufficiently powerful computer to process this data and give us our
> >predictable outcome. But if we had, we could predict the outcome!
>
> >We now use Big Blue and make our calculations based on a given assigned
> >starting point or initial conditions with certain ping pong balls
> >located in specific places in space with certain velocities and spins,
> >etc. After about five days and several games we determine a string of
> >100,000 numbers with each number being from 1 to 80.
> >So the argument is twofold: first randomness is relative. What is
> >random for some is predictable and non random for others. And secondly,
> >computer programs can produce genuinely true random numbers.
>
> >I rest my case.
>
> >And may you rest in peace trying to refute what I have described and
> >concluded because you will surely die trying.
>
> Actually, you have put forth a good argument here.
>
> Rolling dice, or picking lottery balls - those are classical physical
> processes. If they're sufficient to produce what is accepted as "true
> randomness", then, why wouldn't an _equally detailed_ computer
> simulation be acceptable?
"Equally detailed" means running a simulator for the universe. This is not a
productive direction because debugging the simulator will be an (ahem) big
job.
The real universe is already debugged. We should just use it.
>
>
> One important point - a large amount of randomness goes into the
> starting conditions of the physical version. We don't measure the
> positions and velocities of all the air molecules in the room. We
> don't measure the size of the cage with the balls to twenty decimal
> points.
>
> But if we use a pure computer program, without a source of true
> randomness to scatter the initial conditions in a way unknown to us,
> then we don't have all the free initial entropy that a physical
> randomizer gives.
>
> Computer programs can produce cryptosecure pseudorandom sequences.
> Mimicing a physical system would be an extraordinarily inefficient way
> of doing so.
>
> You may well claim that distinguishing that sort of random number
> stream from those produced by dice by calling the one "pseudorandom"
> and the other "truly random" is only quibbling.
>
> However, look at it from the other point of view: while an algorithmic
> method of generating pseudorandom numbers can be very, very good, it
> doesn't have to be. So, if one person can call his algorithmically
> generated numbers "truly random", what about the next person, with a
> somewhat simpler generator, and the next person after him?
>
> Far better to keep claims straightforward. One fellow generates random
> numbers from noise in gas tubes or something - these are true random
> numbers, subject to certain cautions and limitations. Those who
> generate random numbers algorithmically - they explain what algorithm
> they're using, and make claims about how good their techniques are -
> how well they approach the ideal of true randomness (which physical
> systems fall short of, but in a different way).
>
> And people judge their offerings by the quality of the PRNG - its
> level of cryptosecurity. But no one is charged with the task of
> setting a boundary where more secure PRNGs are called "truly random"
> while less secure ones are only pseudorandom.
>
> Yes, one can design a cipher - and it doesn't have to be a stream
> cipher - that allows itself a larger key, and a longer running time,
> than necessary for 'just enough' security. But if I can already claim,
> with perfect justice, that my method offers more security than anyone
> could possibly need - why should I go further, and spoil everything,
> by claiming that my method is _perfect_? When that is not *strictly*
> true, even if the computer big enough to prove it in practice could
> never be built.
>
> John Savard (teenerf is spelled backwards)
> http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Another extension to CipherSaber
Date: Fri, 26 Feb 1999 05:40:35 GMT
In article <[EMAIL PROTECTED]>,
Darren New <[EMAIL PROTECTED]> wrote:
>Actually, having done both many times, hex is *way* easier, because you
>only have to deal with one byte at a time. You can even go so far as to
>make up an array of 256 two-byte strings to do the translation, if your
>language can't handle masks and shifts, for example. Lots of languages
>(incl JavaScript) let you translate bases, so hex<->binary becomes a
>library function rather than a piece of code. Given the continued
>increase in telecom speed, I don't think the bit savings are
>significant, especially since you're assuming a minimum of hardware
>capabilities to start with.
Hex is fine with me. Transmission speed over most dialup modems will
be approx. the same whether hex or 6-bit, because the modem data
compression will squish either coding to close to 8 bits/byte. The
issue is just getting a bigger disk file at each end.
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
