Cryptography-Digest Digest #977, Volume #8 Wed, 27 Jan 99 09:13:06 EST
Contents:
Re: Random numbers generator and Pentium III (Nathan Kennedy)
Re: Random numbers generator and Pentium III (Nathan Kennedy)
Re: hardRandNumbGen (handWave)
Re: Pentium III... (Gurripato (x=nospam))
My comments on Intel's Processor ID Number (Bruce Schneier)
lexical analysis problem.... ([EMAIL PROTECTED])
Re: lexical analysis problem.... (Bauerda)
US5706218 patent (was RNG and Pentium III) (Francois Grieu)
Re: Entrust Developer Tools (Michael Schmidt)
Re: What is left to invent? ([EMAIL PROTECTED])
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: My comments on Intel's Processor ID Number ("Trevor Jackson, III")
Re: lexical analysis problem.... ("Trevor Jackson, III")
Re: Unicity, DES Unicity and Open-Keys (Mok-Kong Shen)
Re: What is left to invent? ("Trevor Jackson, III")
Re: Foiling 56-bit export limitations: example with 70-bit DES (Mok-Kong Shen)
Re: hardRandNumbGen (Patrick Juola)
Re: Unicity, DES Unicity and Open-Keys (Patrick Juola)
----------------------------------------------------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Wed, 27 Jan 1999 05:31:35 +0800
Matthew Skala wrote:
>
> In article <[EMAIL PROTECTED]>,
> Nathan Kennedy <[EMAIL PROTECTED]> wrote:
> >Then all Intel has to do to read your message is grab the processor ID,
> >guess the small startup value, and then zip through the RNG stream until
> >they get to the point where things start to correlate.
> >
> >Sounds good, right?
>
> I don't think it's plausible that Intel could do this and get away with it.
I don't either. I'm just pointing out a possibility, even if theoretical.
You can't look at the numbers and say they're secure.
> In the first place, almost any processing or hashing of the random numbers
> out of the PIII generator would destroy the patterns. Feed it into Linux
> /dev/random, for instance, and although what comes out will be flawed in a
> technical sense, I don't believe that NSA nor anybody else could actually
> crack it. The PIII generator can't be something like an LFSR or we'll
But if all /dev/random is going on is the PIII RNG (which is extremely
plausible, since that would eliminate the kludge for entropy
hunter-gatherers spread all over the kernel, and it would provide a single
good source for entropy on demand), then how much REAL entropy are you
getting from /dev/random? Very little. If your only entropy source is a
compromisable PRNG, then no matter the postprocessing you're not going to
get entropy from nowhere. Of course if you only ADD the PIII RNG, then the
quality of urandom is the same, but random's is substantially decreased. I
mean, the entropy estimate would be WAY off, since if PIII RNG is
essentially 0 bits of entropy, while generating huge amounts of fake
entropy.
<snip>
> Now, consider that as soon as the PIII becomes available, people like
> Cyrix will be flipping the lid and looking at it through a microscope.
> They'd do that *anyway*, it happens to all new processors - this
> controversy just makes it even more a priority. A genuine TRNG based on
> thermal noise is easy to implement in hardware and only takes up a little
> space. But a nontrivial PRNG, strong enough to pass statistical tests
> (such as the SHA1-based system you described) is much more complicated.
> If there's a large block of logic on the chip that doesn't have a good
> reason to be there, people will start asking tough questions. I don't
> think Intel could hope to keep such a secret longer than a month or two,
> and the consequences for them when it was discovered would be horrible.
True. This is probably the biggest issue.
> There is one possibility I see to make this work: what if they had two
> versions of the chip, one (sold to almost everyone) with a real TRNG, and
> a different one (sold only to special targets) that had a "cooked" RNG.
> You don't even need Intel to be the bad guys, NSA could intercept
> shipments of PIIIs destined for people they want to watch, and replace
> them with special chips they made up in their secret fab. (Like some of
> the suggestions that have been made regarding KGB tampering with GOST
> S-boxes.) But if you have reason to think you might be a target of a
> special attack like that, then just don't trust your PIII generator by
> itself.
Right. Intel simply is not in a position to try something like this on a
widescale basis, in practice it would be found out. Obviously, even the
government would have way more motivation and means to do this kind of
thing...
> I would treat the PIII random number generator as another source of
> entropy for my entropy-pool generator, and I wouldn't be afraid of Intel
> cooking it.
Right, I would do the same... But if we stop having conspiracy theories,
then who will find out the conspirators? ;-)
Nate
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Tue, 26 Jan 1999 07:01:18 +0800
> student wrote:
> > 2. How can we know, that RNG embedden in Pentium III is really random ?
> > Are there any methods to detect any subtle pattern in data from the RNG,
> > if there are any (if there are any methods, please describe them)? It is
> > possible to design "Random" Numbers Generator with such a pattern, give
> > it to people, and in this way we have a something like key-escow
> > ciphers.
No subtle pattern is necessary. If Intel was hostile and did it right,
there would be no way to find a "subtle pattern" without breaking SHA-1 or
some hash function that they implement, or reverse-engineering the
processor.
Here's the "hostile Intel" model RNG: Simply use an IV of Intel's secret
128-bit key+public processor ID+small startup value which is incremented
every time the chip powers up. Use this IV as the seed for some secure
hash-based PRNG.
Then all Intel has to do to read your message is grab the processor ID,
guess the small startup value, and then zip through the RNG stream until
they get to the point where things start to correlate.
Sounds good, right?
Nate
------------------------------
From: handWave <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 02:35:56 -1000
Terry Ritter wrote:
>
> On Mon, 25 Jan 1999 04:44:51 -1000, in <[EMAIL PROTECTED]>, in
> sci.crypt ".ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ."
> <[EMAIL PROTECTED]> wrote:
>
> >On Sun, 24 Jan 1999 03:53:40 -1000, in <[EMAIL PROTECTED]>, in
> >sci.crypt <[EMAIL PROTECTED]> sinewave wrote:
> >
> >>Terry Ritter wrote:
> >>Easy calculations using the publushed results show that the effective
> >>population of values is 1/4 the claimed ideal, which shows that the
> >>design was not as good as you thought.
> >
> >Correct, that first version in that report had an XOR gate placed in
> >a bad position, causing twice as many ones as zeros. The CIA alerted
> >us to my mistake with that one gate. When removed, the results are
> >much better. I still regret my mistake in that one gate placement.
>
> Thank you for the confirmation. Usually I hear about my mistakes.
>
> Apparently I was able to detect a problem in the design which your
> team and famous consultant did not, but which the CIA apparently also
> detected.
>
> In other words, my analysis was contrary to your beliefs and those of
> your crypto expert, but was also correct.
>
> So why are you not listening to me now?
I am listening. My silence for 24 hours does not mean I am not listening.
And the consultant we used did not work on the RNG, he worked on the hash
function, only. Your messages are beginning to repeat themselves, so I am
not responding to these repeated comments. Thank you for a rational
discussion of this subject. If you post more on this subject , I will be
reading them, but not always responding.
.ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ..ˇ´¯`ˇ.handWave
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Pentium III...
Date: Wed, 27 Jan 1999 08:13:07 GMT
On Mon, 25 Jan 1999 17:59:10 GMT, Darren New <[EMAIL PROTECTED]>
wrote:
>> >The serial number in the chip is to help control the trade in stolen CPUs,
>> >which is a big moneyspinner in certain parts of the criminal world.
And, naturally, the desire from the FBI,CIA,NSA ...... (your
favorite 3-letter agency goes here) to control people´s actions and
movements, regardless of whether you belong to the bad guys or not, has
NOTHING to do with it.
>> Once again the law-abiding citizen has to pay the price for the
>> ineptness of law enforcement.
I would rather say data-greed. They are far from inept.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: My comments on Intel's Processor ID Number
Date: Wed, 27 Jan 1999 02:56:52 GMT
I wrote a column on Intel's Processor ID number for ZDNet. You can
read it at:
http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED]
Subject: lexical analysis problem....
Date: Wed, 27 Jan 1999 10:07:56 GMT
I'm looking for a quick way of finding all words whose letters add up to 111.
Each letter in the english alphabet is allocated the value of its respective
position in the alpahabet (i.e. A =1, B=2, C=3 and so on).
An example would be "computer" which is 3+15+13+16+21+20+5+18 = 111
All possible permutaions would range bewteen words 111 letters long (all A's
being an example) and words at least 5 letters long (max value of 4 letters
long is ZZZZ which is 104). Since I'm looking for real words in the English
dictionary I have placed an upper bound on the word length to 15 letters.
So my problem - how to find all permutations of words between 5 and 15 letters
long that add up to 111. A brute force algorithm would take far to long since
26^15 calculations and comparisons would need to be performed. An idea I had
was building a table of letters representations ie.
A is equiv to only an A
B is equiv to AA, B
C is equiv to AAA, AB, BA, C
D is equiv to AAAA, AAB, ABA, BAA, AC, CA, D
and then using this from some base that adds up to 111 and do all possible
substitutions.
i.e. If we were looking for words adding upto 4 then we would get
base case = AAAA
subs for B's = AAB, ABA, BAA
subs for C's = AC, CA
subs for D's = D
This is the same as the equivalency list for D. What base should I use to
ensure all permutations are reached? If we allowed words of 111 letters long
then the base would be 111 A's. What about for words 15 letters long?
Any thoughts out there?
Rob.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: lexical analysis problem....
Date: 27 Jan 1999 12:08:51 GMT
>I'm looking for a quick way of finding all words whose letters add up to 111.
>
>Each letter in the english alphabet is allocated the value of its respective
>position in the alpahabet (i.e. A =1, B=2, C=3 and so on).
>
>An example would be "computer" which is 3+15+13+16+21+20+5+18 = 111
>
>All possible permutaions would range bewteen words 111 letters long (all A's
>being an example) and words at least 5 letters long (max value of 4 letters
>long is ZZZZ which is 104). Since I'm looking for real words in the English
>dictionary I have placed an upper bound on the word length to 15 letters.
>
>So my problem - how to find all permutations of words between 5 and 15
>letters
>long that add up to 111. A brute force algorithm would take far to long
>since
>26^15 calculations and comparisons would need to be performed. An idea I had
>was building a table of letters representations ie.
You begin by saying that you are looking for words, if so then don't do a brute
force for letter combinations and then pick the words out of that, get a
dictionary and do a brute force search against it.
David Bauer
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: US5706218 patent (was RNG and Pentium III)
Date: Wed, 27 Jan 1999 13:10:42 +0100
Intel filed US 5,706,218 patent in 1996 for a RNG :
"A random number generator using a single, slow, voltage controlled
oscillator which receives a noise input and a plurality of high frequency
ring oscillators. The ring oscillators are sampled under control of
the slow oscillator. A circuit is used between the output of each of
the ring oscillators and its respective D-type latch to assure that
the sampling is unbiased, that is, that there will be near even
distribution of 1s and 0s in the random numbers."
The patent is available at
<http://patent.womplex.ibm.com/patlist?icnt=US&patent_number=5706218>
with pointers to a scanned version, including schematics at gate-level
and transistor-level.
Maybe (only my speculation) this could be the design of Intel's RNG
for the Pentium III. If it is, I fear that the ring oscillators
(operating at about 600 MHz according to the text) will have a tendancy,
in some temperature/supply/individual chips combination,
to synchronize with whatever ripple is on the power supply rails,
somewhat reducing the entropy one gets out of the whole thing.
Francois Grieu
------------------------------
From: Michael Schmidt <[EMAIL PROTECTED]>
Subject: Re: Entrust Developer Tools
Date: Wed, 27 Jan 1999 13:16:34 +0100
It may be interesting for others that access to this site from outside
North America currently is not possible.
Entrust promises to make it possible in the future.
> Just in case folks are interested I found out today that the Entrust
> toolkits are available for downloading. It used to be that you had to pay
> a large hunk of change to get your hands on them, but I guess they have
> changed their tack. I briefly glanced at their web site www.entrust.com (
> I think they have a http://developer.entrust.com site as well.
>
> Anyways I think they are giving away the development tools and a mini PKI
> setup for developers. It is all for the downloading.
>
> Check it out yourself as I may have gotten the facts wrong .
--
Michael Schmidt |
Utimaco Safe Concept GmbH | Tel: ++43 732 655 755 - 35
Europaplatz 6 | Fax: ++43 732 655 755 - 5
A-4020 Linz, Austria | E-Mail: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is left to invent?
Date: Wed, 27 Jan 1999 12:34:54 GMT
In article <[EMAIL PROTECTED]>,
Toby Kelsey <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
> >Since any cipher can be broken by trying to decode the message with all
> >possible keys,
>
> Only if you can identify the plaintext when you see it.
>
> Toby
> --
> Toby Kelsey
>
This is a good point - I have a crafty friend that uses a wraparound
dictionary function that replaces words for other words in his dictionary (of
course only when the source word is present in his dictionary) which he uses
with other friends of his. Even when you look at the plain text (if you can
get THAT far) its still meaningless without the ditionary and inverse
function.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 27 Jan 1999 11:58:16 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <78ko3a$ueb$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> > The Wassenaar Arrangement [WA, WA98] can be seen as defining a
> > current lower limit for the bit-length security parameter of
> > symmetric ciphers, which should be larger than 64-bits. However,
> > ciphers that obey this very limit cannot be freely exported -- due to
> > the export limitation of 56-bits imposed by the WA.
> >
> ......
> >
> > In summary, the concept of open ignorance was exemplified with 56-bit
> > DES encryption and shown to easily bootstrap key-length by a large
> > factor to e.g., 70-bits -- without breaking any export restriction on
> > the 56-bit limitation since all 2^14 random blocks are pre-defined
> > and publicly known. Which raises the attacker's perceived bit-length
> > even above the limit of controlled export [WA98], of 64-bits for
> > symmetric ciphers such as DES.
> >
> You might get complaints that anything that subverts the really moronic,
> 1960-computer-thinking is in itself a violation.
>
;-) actually, that is the key to solve the problem. As Einar Stefferud is
found of saying, the Internet is edge-controlled -- we are the edges. And,
the Internet way is just to route around damage. Be it host servers or civil
servers ;-)
> For instance, why not parse a body of plaintext into several parts, short
> block transposition style, using several different DES alternately to
> encrypt the reassembled input data. You could do it in such a manner that
> would reduce the amount of original running plaintext snippits to less
> than required for solution of a single DES key, and the sequence and
> number of DES keys could be secret, as well as the keys themselves.
Will not work. DES unicity is **only** two letters of text. Please see the
paper quoted -- Sections 6 and 7 -- http://www.mcg.org.br/unicity.htm
It is a mistake in the literature to consider DES unicity to be 20 bytes (3
blocks of DES) for compressed English. The formula is simply not valid in that
range as proved in the paper.
Cheers,
Ed Gerck
> A much too common philosophy:
> It's no fun to have power....unless you can abuse it.
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Wed, 27 Jan 1999 08:25:02 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Roger Schlafly wrote:
> Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
> >I wrote a column on Intel's Processor ID number for ZDNet. You can
> >read it at:
> >
> >http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
>
> Your analogy is to a national ID number which is on a card that no
> one examines. Hence it is useless for identification, you argue.
>
> But that is almost precisely what we have. I have a Social Security
> number, but I have never shown my card to anyone because I lost
> it long ago. And yet my SSN is still used for identification.
There are two interpretations of the phrase "used for ID". One is proof
of ID and the other is uniqueness of ID. He is using the former in the
sense of authentication. You are using the latter in the sense of
labeling.
------------------------------
Date: Wed, 27 Jan 1999 08:32:51 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: lexical analysis problem....
[EMAIL PROTECTED] wrote:
> I'm looking for a quick way of finding all words whose letters add up to 111.
>
> Each letter in the english alphabet is allocated the value of its respective
> position in the alpahabet (i.e. A =1, B=2, C=3 and so on).
>
> An example would be "computer" which is 3+15+13+16+21+20+5+18 = 111
>
> All possible permutaions would range bewteen words 111 letters long (all A's
> being an example) and words at least 5 letters long (max value of 4 letters
> long is ZZZZ which is 104). Since I'm looking for real words in the English
> dictionary I have placed an upper bound on the word length to 15 letters.
>
> So my problem - how to find all permutations of words between 5 and 15 letters
> long that add up to 111. A brute force algorithm would take far to long since
> 26^15 calculations and comparisons would need to be performed. An idea I had
> was building a table of letters representations ie.
>
> A is equiv to only an A
> B is equiv to AA, B
> C is equiv to AAA, AB, BA, C
> D is equiv to AAAA, AAB, ABA, BAA, AC, CA, D
>
> and then using this from some base that adds up to 111 and do all possible
> substitutions.
>
> i.e. If we were looking for words adding upto 4 then we would get
>
> base case = AAAA
> subs for B's = AAB, ABA, BAA
> subs for C's = AC, CA
> subs for D's = D
>
> This is the same as the equivalency list for D. What base should I use to
> ensure all permutations are reached? If we allowed words of 111 letters long
> then the base would be 111 A's. What about for words 15 letters long?
>
> Any thoughts out there?
Hint: avoid doing this search "the hard way". Rather than enumerating every
string and trying to determine whether the strings are valid english words, start
with english words and add them up. To do this you need a comprehensive source of
english words. I recommend the OED CD.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 14:34:41 +0100
wtshaw wrote:
>
> I've stumbling more onto, lets us say, novel means of simple, basic
> compression, more information in fewer characters. The idea is to vary
> such methods and incorporate them more closely with the encryption
> itself....these best described as "bucket" ciphers, somewhere between
> block and stream ciphers, are still in the scratch paper phase, and will
> be explained in detail once they start being born...implemented.
I am looking forward to your design. A couple of tiny comments:
(1) one couldn't get better compression than along the lines of
Huffman (variants possible) unless one resorts to code books
(including 'public' code books, if such can be realized) (2) combining
stream and block encoding appears to be useful (see my WEAK3).
> >
> > More generally: It is commonly assumed that the analyst knows the
> > encryption scheme one uses. But this is reasonable if one repeatedly
> > uses the same scheme. If one has a fairly large set of schemes to be
> > chosen according to a secret schedule, then the analyst has first of
> > all to figure out the scheme actually being used, i.e. he has a much
> > higher work load. I believe all this could be subsumed under the
> > paradigm 'Security through variability', which underlies, in
> > particular, those algorithms that are parameter-dependent (analogous
> > to parametrized data types in programming languages; the parameters
> > can be regarded as kind of 'key extensions' which is of interest
> > in the context of the Wassenaar regulation).
>
> What is needed is a multitude of algorithms, with view as to what output
> is produced. Recently, I began posting some rather simple, probably dumb,
> ciphers, whose goal is more than anything to add more straw to the pile.
With parametrized ciphers, choosing different parameters gives you
different ciphers, even though these work on the same basic
principles.
M. K. Shen
------------------------------
Date: Wed, 27 Jan 1999 08:37:50 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Toby Kelsey <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes
> > >Since any cipher can be broken by trying to decode the message with all
> > >possible keys,
> >
> > Only if you can identify the plaintext when you see it.
> >
> > Toby
> > --
> > Toby Kelsey
> >
>
> This is a good point - I have a crafty friend that uses a wraparound
> dictionary function that replaces words for other words in his dictionary (of
> course only when the source word is present in his dictionary) which he uses
> with other friends of his. Even when you look at the plain text (if you can
> get THAT far) its still meaningless without the ditionary and inverse
> function.
I think the technical term for your friend's dictionary is codebook. Codes are
fundamentally distinct from ciphers. They also have no particular value in
hiding plaintext. The test for "making sense" is fundamentally distinct from
"making text".
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 27 Jan 1999 14:14:50 +0100
wtshaw wrote:
>
> For instance, why not parse a body of plaintext into several parts, short
> block transposition style, using several different DES alternately to
> encrypt the reassembled input data. You could do it in such a manner that
> would reduce the amount of original running plaintext snippits to less
> than required for solution of a single DES key, and the sequence and
> number of DES keys could be secret, as well as the keys themselves.
This is certainly a viable method. I mentioned it in an article,
saying that an algoritm (with different keys) can be applied in
parallel, see http://www.stud.uni-muenchen.de/~mok-kong.shen/#paper17
But the proposed method of Ed Gerck is also a viable and interesting
method for coping with the Wassenaar regulation. It is further
an instance of the paradigm Security through Inefficiency.
M. K. Shen
coping
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 27 Jan 1999 08:37:36 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
>>
>> On Tue, 26 Jan 1999 13:33:49 +0100, Mok-Kong Shen
>> <[EMAIL PROTECTED]> wrote:
>>
>> >If I have two sources of randomness, one software and one hardware,
>> >both passing all statistical tests I apply equally well, why should
>> >I choose one source in preference to the other?
>>
>> Why do you persist in believing that statistical tests have anything
>> to do with randomness in cryptography?
>
>Tell me what other (better) tools are available for me to make
>the decision. These are simply easy to obtain, as far as my
>humble knowledge goes. Please kindly give your recipe to cope with
>the situation I described. Thanks in advance.
There's an old joke about a man losing a quarter and looking for
it on the wrong corner "because the light is better here." Or
as another metaphor, if I have two used cars, one a Chevrolet and
one a Ford, both with identical option packages, which one's the
better buy?
Only an idiot buys a used car on the basis of the option package;
anyone with any sense will look under the hood, test drive it, and
so forth. And if you know nothing at all about engines, if you're
sensible you'll get a knowledgeable friend or a professional mechanic
to look at it and figure out whether or not it's got some lurking
evil hiding in the clutch master cylinder. (No, I'm not bitter about
that old Renault. Not at all!)
You *can't* evaluate a random number generator based only on the
statistical properties of the stream it produces. Yes, we've got
lots of useful statistical tools that will tell you if it's producing
an obviously biased stream, and if it can't pass them, then it's
not very good.
*BUT* that's not enough. You are going to have to open the hood and
look at the engine and see how it's put together. Lots of things
that *look* random -- LFSRs, congruential generators, "chaotic function"
generators -- have been cracked. Lots of apparent hardware randomness
solutions have subtle, or not so subtle, biases. Lots of people have
written lots of buggy code.
At this level of evaluation, there are no *tests* per se, although
there are lots of informal checks. E.g., if someone uses a PRNG
with a 32-bit seed, that's not random enough. If someone uses
a pure LFSR, it doesn't matter *how* large the seed is, it's not
secure. And so forth. But the idea that if you can't run a formal
test or if there isn't a software package to do the work for you,
it doesn't matter, is pure and unadulterated bullshit.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: 27 Jan 1999 08:41:01 -0500
In article <[EMAIL PROTECTED]>,
wtshaw <[EMAIL PROTECTED]> wrote:
>In article <78kqke$jpk$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(Patrick Juola) wrote:
>
>> In article <[EMAIL PROTECTED]>,
>
>> How large is "a fairly large" set of schemes, in this context?
>> I'm rather suspicious of introducing a thousand new and insufficiently
>> tested encryption algorithms in the interests of adding another ten
>> bits of security. On the other hand, I don't see creating another
>> three bits of key as necessarily being useful; that puts off the
>> apolcalypse for, what, two years (Moore's law and all)?
>>
>Speaking of numbers, surely a few impressive ciphers are nice to have, but
>overwhelming with multitudes of choices is as good a cipher technique as
>it is a battle tactic.
Not if most or all of the choices suck. As true in battle as it is
in cryptography.
>Besides that, there are subtile things to be learned about ciphers and
>functionality through experience with as many different ones as possible.
>If for any other reason, having fodder for budding attackers somewhere
>between trivial and megalithic seems like a good idea.
This I agree with. *But*, once we've found that the WizBang16 doesn't
work and can be cracked in a few minutes/seconds, is it still a viable
choice?
-kitten
------------------------------
** 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
******************************
