Cryptography-Digest Digest #984, Volume #8 Wed, 27 Jan 99 20:13:05 EST
Contents:
Re: What is left to invent? (R. Knauer)
Re: Unicity, DES Unicity and Open-Keys ([EMAIL PROTECTED])
Re: My comments on Intel's Processor ID Number (Bruce Schneier)
Re: Who will win in AES contest ?? (DJohn37050)
Re: Who will win in AES contest ?? (Bruce Schneier)
Re: hardRandNumbGen (R. Knauer)
PWL files (Aknow)
Re: hardRandNumbGen (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: Metaphysics Of Randomness (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: My comments on Intel's Processor ID Number (John Savard)
quick newbie question (AbsolutAF3)
Re: hardRandNumbGen (R. Knauer)
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Wed, 27 Jan 1999 22:21:40 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 26 Jan 1999 12:51:50 +0000, Toby Kelsey
<[EMAIL PROTECTED]> wrote:
>>For example, if your key is 56 bits, like with DES, then any
>>intelligible message you uncover over 8.2 bits will be the intended
>>message with high confidence. If you uncover a message that is
>>significantly longer than 8.2 bits, then it is almost certain to be
>>the intended message.
>This presumes that decipherments always fall randomly in the space of
>all possible (intelligible or not) messages.
Why do you say that?
>It is this unjustified assumption I am questioning
>(not for DES, but encryption in general).
I questioned it too back a year ago when we had a long session about
the OTP.
I was told that the probability for an intelligible message, other
than the intended message, is vanishingly small when the message
length exceeds the unicity distance. Therefore only one possible
plaintext is intelligible - your intended message.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Unicity, DES Unicity and Open-Keys
Date: Wed, 27 Jan 1999 23:05:15 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> >
> > For special protocols, in high-security applications, the "magic numbers"
can
> > also be implicit or encoded with a random seed in each use. However, the
> > encoded data itself may betray its presence by its very structure, size,
> > range, randomness, redundancy, etc. This is a problem in identification and,
> > as given in [Ger98], "to identify is to look for connections" -- not just to
> > look for an identity connection with a set of "magic numbers". For further
> > discussion on this topic and a practical example please see [Ger99],
Section
> > 4.
>
> I look forward to be able to study the forthcoming version of your
> paper, though I am not yet quite sure that the task of identification
> or analysis of compression (if appropriately done for cryptography)
> is as straightforward as your text above apparently suggests.
>
Please see the practical example in the reference quoted, for Huffman coding.
The same can be applied to other compression methods. Note further that
several compression methods rely on "autocode", which is a name for "uniquely
decodable code" -- or, a sitting duck, by another name '-)
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: My comments on Intel's Processor ID Number
Date: Wed, 27 Jan 1999 23:30:47 GMT
On Wed, 27 Jan 1999 16:16:59 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>
>>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
>
>However, according to claims I've read about the Intel processor ID
>number, it will include a digital signature by Intel. So the validity
>of a processor ID number can be checked.
I have heard the exact opposite.
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] (DJohn37050)
Subject: Re: Who will win in AES contest ??
Date: 27 Jan 1999 22:08:22 GMT
My submitted paper is on Future Resiliency which suggests that perhaps there
should be more than one AES winner.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Who will win in AES contest ??
Date: Wed, 27 Jan 1999 23:36:47 GMT
On 27 Jan 1999 20:59:41 GMT, [EMAIL PROTECTED] (Markus Kuhn) wrote:
>Ross also quoted an AsiaCrypt
>presentation by Eli Biham, where the performance of AES candidates
>was compared when the number of rounds was normalized to equal
>protection against known attacks, and suddenly Serpent and Twofish
>became the two fastest algorithms.
Be careful. Biham's numbers don't make a whole lot of sense. First,
he didn't normalize the number of rounds to equal protection against
known attacks, he normalized them to what he thought was secure plus
two rounds. Some of his choices for round numbers are very
questionable. Second, he chose to add two rounds to his normalized
numbers. This doesn't make sense, either, since by his first
assumption each cipher's rounds are of different strength. And also,
he ignored the different pre- and post-processing that some ciphers
have; this affects security as well. So don't put a lot of
credibility in these calculations.
>So those of you who print performance tables and ranking lists
>might want to include an entry for 16-round Serpent as well ...
Only if it becomes an AES submission.
>Brian Gladman made in his presentation also the interesting
>suggestion that the AES contest should select not a single
>but three winners. These winners should be diverse in their
>technology, such that a cryptoanalytic breakthrough could
>not kill all three of them simultaneously. For instance,
>we could have one simple easy to validate high-performance
>winner (RC6?), one ultra-conservative winner (Serpent?), and
>one winner that performs nicely on 8-bit embedded controllers
>with only a few bytes of RAM and a few hundred bytes of ROM.
I think that would be a disaster.
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] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:37:37 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 19:36:17 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>But he has a right to demand that the security
>offered by a system be demonstrated.
Fine - let him seek a meaningful demonstration then.
>Simply saying that a hardware
>generator offers high security
No one ever said that.
>Now for a random
>number sequence I don't know any way to provide such data excepting
>through statistical tests.
Statistical tests do not prove randomness if they are applied to
finite numbers.
>And by the discussions till now you
>also don't know a way.
That's because there is no way, other than to let the TRNG generate an
infinitely long number.
>So it is my opinion that using statistical
>tests at least gives him something concrete for him to form a more
>or less objective opinion, even though we should tell him that the
>tests are questionable for this and that reason.
"Questionable" is a weasel word for meaningless.
Statistical tests are useless if applied to finite random numbers
generated by a TRNG.
>This is anyway
>better than leaving him with nothing to form a (subjective) opinion
>of the encryption scheme he is using.
If a test is worthless (except to diagnose a major malfunction), how
is it any good?
Actually, it is worse than not using it because it can give a false
sense of confidence.
>Have I expressed my arguments clearly?
Yep, it is clear that you are as confused as ever.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: Aknow <[EMAIL PROTECTED]>
Subject: PWL files
Date: 27 Jan 1999 23:00:46 GMT
I have some questions about the algorithm for encrypt/decript
pwl file of MS Windows.
I have found the source of GLIDE but the algorithm seem to be
not complete and to have some errors.
There is a correct copy, and where I can find a full explanation
of the algorithm? What does Win when the user logs on with password?
Is RC4 algorithm unique or MS has a modified one?
P.S. Excuse me for my bad english and for my stupid question.
Jeppetto.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:44:42 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 16:00:55 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> Algorithmic analysis of the generated output itself is completely
>> worthless if that output is finite in length. If the number 111...1 is
>> generated by a TRNG, then it is a perfectly valid crypto-grade random
>> number, just like all the other 2^N-1 numbers of the same length.
>False. Analysis of output is insufficient to prove the entropy density is
>100%, but it can easily provide useful information.
I never said it couldn't. However, analysis of the output of a TRNG is
not useful for purposes of crypto.
>For instance, a page of
>business text is around 2^16 bits (of data, not information). If we divide up
>the (?)RNG output into samples of this size we can establish a confidence that
>the samples are statistically random.
Define "statistically random" in terms of finite length numbers.
>If the samples are not statistically
>random, we can, with statistical confidence, eliminate that RNG as appropriate
>for key generation.
Define "not statistically random" in terms of finite length numbers.
Remember we are talking about crypto-grade randomness, where it is
possible to use a random number as a pad in the OTP cryptosystem,
which means it must be proveably secure.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:46:31 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 14:32:25 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>The larger the key, the more difficulty you have in changing/exchanging
>it.
>If you're going to exchange 10,000 bytes of code, why don't you use
>the same mechanism to exchange a 10,000 byte RSA key or something like
>that, which gives you much more bang/buck?
The question was theoretical.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Wed, 27 Jan 1999 22:52:00 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 14:58:49 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>A user of a piece of equipment can inspect 2, but they only
>>have statistics to tell them if the RNG is actually working.
>Yes. But if they *only* have the stats and can't check the
>design and the shielding, then the stats don't mean much.
Clarification, please.
Are you saying that there are general statitical tests to check that a
TRNG is working - other than the trivial tests for all 1s or all 0s?
If so, what might those stats be?
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:54:24 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 14:27:50 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>English text contains just over one bit of randomness per character.
>If you need a thousand bits of randomness, get a thousand characters
>of English text from a secure source, distill them appropriately with
>a trusted hashing function. Better yet, get 1500 characters to allow
>for sloppy engineering -- you'd never run a wire at its rated wattage,
>would you? Take the resulting 1000 bit string, XOR it with the plaintext,
>and voila. A scientifically sound method of securing 1000 bit secrets.
You once said that such a system was vulnerable to a Bayesian attack.
Have you changed your mind?
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:50:54 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 15:44:49 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> How about making your algorithm (code) part of the key? That way you
>> could change algorithms as often as you change keys.
>In theory you can do this by encoding the algorithm appropriately.
Any suggestions on how to do that?
>However, you
>need a clever encoding scheme such that all key values translate to valid
>algoirhms.
A daunting task.
>In addition, you need to show that all such encoded algorithms are
>"secure".
A daunting task.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:56:10 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 15:06:39 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>Um... the NSA does *NOT* have infinite resources. Far from it.
>The GNP of the United States is only measured in the trillions,
>so any hardware costing more than a quadrillion dollars or so is
>probably out of reach.
Not when the federal reserve can make all the fiat money it wants.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: My comments on Intel's Processor ID Number
Date: Thu, 28 Jan 1999 00:06:30 GMT
[EMAIL PROTECTED] (Bruce Schneier) wrote, in part:
>On Wed, 27 Jan 1999 16:16:59 GMT, [EMAIL PROTECTED]
>(John Savard) wrote:
>>However, according to claims I've read about the Intel processor ID
>>number, it will include a digital signature by Intel. So the validity
>>of a processor ID number can be checked.
>I have heard the exact opposite.
You certainly could be right.
At the Intel site, there is very little information about the Pentium
III, only that its brand name is now official.
News articles quoted in various Usenet groups have given some details.
Apparently, its main feature is the long-awaited MMX 2 instruction
set, with the ability to handle vectors with multiple floating point
numbers in them. Also higher clock speeds.
Out here, in the cryptography-related groups, the processor ID and the
hardware random-number capability were mentioned. I couldn't find
reference to either feature among Intel press releases.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (AbsolutAF3)
Subject: quick newbie question
Date: 27 Jan 1999 23:21:48 GMT
Does anyone know where I can get software that would expidite the solution of a
subsitution cipher (Letter frequency analysis, dictionary checking, etc...)?
Preferably dos/win but any will do. Thanks for your time.
B
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 23:26:06 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 19:19:57 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>How do you measure or test the skill of a person designing a TRNG?
>Using some tests of the psychologists??
Make him pee in a bottle and if he does, fire him. If he throws the
bottle at you, hire him.
Skilled people fiercely guard their personal rights as humans. Only
sheep seek the comfort of conformity - and you do not want some sheep
designing a TRNG for you.
>More precisely, how do
>you show through a test of skill that the resulting TRNG designed
>by that person has a certain 'crypto-grade', even if you could define
>that 'crypto-grade' scientifically precisely which I guess you can't.
>Are you excluding that a skilled person could ever make mistakes??
Get several skilled people to check the design and the actual TRNG.
That's why there are standards committees.
But if you attempt to rely on statistical tests on the output alone,
you are not going to know much of anything - except in the trivial
case of a shorted or floating output. But that's it.
If you could determine the randomness of a finite sequence
algorithmically, you could solve both Godel's incompleteness problem
and Turing's halting problem. See Chaitin for the reasons why.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 27 Jan 1999 22:41:15 GMT
In article <78n5b0$l85$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> In article <78m55c$4cd$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> [snip]
> >Please visit the full paper at http://www.mcg.org.br/unicity.htm
> >
> >This specific section was also changed, to make it easier to understand. The
> >new relevant part is:
> >
> >Consider a hypothetical M-DES Standard (hereafter, M-DES) which would specify
> >a total of 2M pre-defined and publicly known 64-bit different blocks of data,
> >for various choices of M = 0, 1, ... Now, when Bob wants to send a message to
> >Alice, he needs to negotiate a M-DES cipher with Alice, which includes a
> >56-bit secret-key [Note-1] and a publicly defined value for M, say M = 14.
> >The value of M is chosen by Bob according to his security needs [Note-2], and
> >accepted (or not) by Alice. To use M-DES, Bob would privately choose one
> >64-bit "key" at will (from the public list of 2^14 "keys") and then
> >repeatedly use this choice to XOR-encode one by one each of all 64-bit DES
> >ciphertext blocks which are calculated with the 56-bit secret-key he shares
> >with Alice -- without disclosing his choice (i.e., anyone else would ignore
> >the choice). Thus, Bob's choice is an "unknown key" to anyone else, including
> >Alice -- providing open ignorance.
>
> Interesting idea. On the other hand, all it really seems to do
> is to slow down Alice's ability to communicate to exactly the
> same degree that it slows down Mike's ability to read her communications.
> So the work factor -- i.e. the ratio between Alice's time to decrypt
> and Mike's -- is unchanged.
>
The objective is to slow down the attacker *much more* than the penalty paid
by Alice/Bob. This is granted because:
1. Both Alice and the attacker ignore the 14-bit unknown-key. Alice knows the
56-bit secret-key but the attacker ignores it. Alice faces a brute-force
attack over a 14-bit keyspace while the atatcker faces a 70-bit keyspace.
2. Alice needs an average of 2^13 DES trials with the known secret-key in
order to find out the unknow-key -- this is about the same time as to
DES-decrypt 64 Kbyte of data, an common amount of work. The same unknow-key
can be used for Bob, so Bob has no such delay. Alos, the same unknown-key can
be used for several messages since the DES ciphertext is random with full
entropy of 8 bit/byte (ie, 2^64 combinations).
3. The attacker however needs to solve an average of 2^69 DES decryptions for
one block (with the revised DES unicity presented in the paper, not three as
usually quoted). To have an idea how much this is, suppose the EFF DES-cracker
would take an average of 40 hours (for 50% search) to break 56-bit DES. Then,
the same DES-cracker would take about a month to break the discussed scheme,
which is equivalent to 70-bit DES.
Thus, Alice and Bob can enjoy 70-bit protection with export-free 56-bit DES.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
