Cryptography-Digest Digest #962, Volume #8 Mon, 25 Jan 99 15:13:03 EST
Contents:
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Sanity check on authentication protocol (Edward Keyes)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Help: Which secret key cipher? ("Trevor Jackson, III")
Re: [req]:Cryptanalysis tool - word pattern table ("Dave Smith")
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Random numbers generator and Pentium III (Mok-Kong Shen)
Random numbers generator and Pentium III (student)
Re: Metaphysics Of Randomness (Alan DeKok)
Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode (Mok-Kong Shen)
Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode
([EMAIL PROTECTED])
Re: Random numbers from a sound card? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 08:47:10 -0500
In article <[EMAIL PROTECTED]>, Boson <[EMAIL PROTECTED]> wrote:
>Your over-use of the adjective "true" is a gradeschool error. Next we
>will need super-duper random number generators: SDRNG. Then Ultra-Pure
>Random Number Generators: UPRNG.
>
>If I gave you two sequences, could you clasify them as coming from a RNG
>vs. a TRNG?
Possibly not. But, on the other hand, if you gave me a sequence, it
would be useless for cryptographic purposes -- for all I know, you give the
same sequence out to any yahoo that asks for it. The question is whether
or not I could reproduce that sequence by breaking into your office -- or
whether I could have five friends buy a sequence from you and then
as a result, I could enumerate your sequence space and figure out the
variety of sequences you have for sale.
You can't evaluate a sequence based only on the sequence. For crypto
purposes, you have to look at the generator as well.
> No. A random number generator produces random sequences of
>numbers.
Yes. But are they random *ENOUGH*? Unless you really know what you
are doing, then the answer is probably "no."
Or to put it another way, a linear congruential random number generator
also produces random sequences. But all the randomness is contained
in your choice of seeds....
-kitten
------------------------------
From: [EMAIL PROTECTED] (Edward Keyes)
Subject: Re: Sanity check on authentication protocol
Date: Sun, 24 Jan 1999 14:38:26 -0500
In article <[EMAIL PROTECTED]>, Antti Huima
<[EMAIL PROTECTED]> wrote:
> This protocol can be summarized as follows:
>
> A --> B: A, R_A
> B --> A: {K, R_A, R_B}_S
> A --> B: {R_B}_S
>
> Here S = the shared secret key, R_A = Alice's random number, R_B =
> Bob's random number, K = the new session key.
>
> In principle this resembles much the Needham-Schroder public-key
> protocol which was shown to be flawed by Gavin Lowe. However, the
> usage of symmetric encryption adds in principle an implicit
> authentication of the second message, assuming that `S' is known by
> Alice and Bob alone. This seems to fix the problem with the NS
> protocol.
>
> The messages 2 and 3 must be accompanied with strong MACs based on the
> shared secret. Without MACs the protocol is not trustworthy.
Thanks. Good point.
> Observe also that Bob can be used as an oracle to generate an
> unlimited number of known plaintext-ciphertext pairs (send A, R_A to
> Bob and you get {*, R_A, *}_S). This is a bad thing.
How bad of a thing is this, since each message will contain a large
amount of unknown random data as well (the newly-generated session
key and R_B)? Can this be fixed by doing something stronger than
concatenation, like bit-interleaving? Or is it just a matter of
"leaking" a certain amount of info with every message?
> There is also a possibility to lure Alice into believing that she is
> communicating with Bob even if Bob has disappeared from the Universe.
> Two protocol runs are interleaved; the protocol numbers are shown in
> square brackets:
>
> [1] A --> B: A, R_A
> [2] I --> A: B, R_A
> [2] A --> I: {K, R_A, R_A'}_S
> [1] I --> A: {K, R_A, R_A'}_S
> [1] A --> I: {R_A'}_S
>
> Here Alice believes incorrectly that the fourth message comes from
> Bob, when it is as a matter of fact generated by herself. This is a
> problem caused by the use of symmetric cryptography. Of course, here I
> does not still know K and is thus not able to continue with the
> communications.
Ah... that is a good point. Thank you. The intended application was
to have the protocol be explicitly client-server, so only Bob generates
session keys. It's good to know that if this is not the case that
authentication problems arise.
I'm definitely glad I posted this... :)
+------------ Edward Keyes, [EMAIL PROTECTED] -------------+
|................ http://web.mit.edu/eakeyes/www/ ................|
|.... DaggerWare: "small, sharp, and with a heck of a point!" ....|
+- "A little inaccuracy saves a world of explanation." C.E.Ayres -+
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 08:30:20 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Fri, 22 Jan 1999 19:20:44 -0500, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>
>
>>> If a secure OTP could be generated from the XOR of two text streams,
>>> who needs a TRNG?
>
>>Sure. That's a valid criticism of the letter-from-Aunt-Jane kind of camoflage, but
>>only if you start with a given letter from Aunt Jane. If you're willing accept *any*
>>letter than looks like it came from Aunt Jane then you aren't mixing two text
>streams.
>
>I don't understand what you just said. If the Aunt Jane letter is
>composed of intelligible text then using it to create the key has
>nothing to do with whether it is from a particular letter or any
>letter.
>
>Please elaborate, in case I missed something here.
It's a question of at what stage you do the filtering. If you
decide, a priori, that you will encypher your message with an OTP,
and then either transmit (iff it looks like English text) or
try again with the following pad section (otherwise), you still,
technically, have perfect secrecy.... It will also take millenia
for you to encrypt, but what the hell.
-kitten
------------------------------
Date: Mon, 25 Jan 1999 13:41:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Help: Which secret key cipher?
Mok-Kong Shen wrote:
> Terry Ritter wrote:
> >
>
> > But if we talk about encrypting an OTP with a master OTP, then,
> > surely, we cannot use the master more than once (or it would not *be*
> > an OTP). And if we cannot expand the amount of keying material in
> > this way, it is hard to see how we could have a hierarchy.
>
> I certainly misunderstood something. But I don't yet fully see an
> 'essential' difference between securing an OTP in a safe with a
> physical key and encrypting the OTP with a master key, since both
> serve to avoid the OTP being acquired by the adversary. (Both keys
> are repeatedly used. The used part of the OTP is discarded in both
> cases.) Could you explain your point a bit more? Thanks in advance.
>
> M. K. Shen
MKS,
Terry Ritter was replying to a poorly written message I left regarding the
changing feasibility of OTPs given the evolution of hardware capacities. I
meant, but did not state, that there is an important difference between
secure communication and secure storage.
An OTP transmitted over a secure channel (courier or something similar)
does not have to be proteced by more key material transmitted over the same
channel. The "master key" I mentioned is a bad term. What I meant was a
locally generated pad used to protect the stored copy of the communication
pads. There is no reuse required because a new "storage key" (instead of
master key) can be generated for each "comm key" received.
I think Terry was concerned for the increase in risk of storing large
quantities of key material for long periods of time; but he can address
that issue if he choses to.
------------------------------
From: "Dave Smith" <[EMAIL PROTECTED]>
Subject: Re: [req]:Cryptanalysis tool - word pattern table
Date: Mon, 25 Jan 1999 13:50:41 -0500
"©ú¥Õ" wrote:
> It would list, for example, a pattern such as "ABACD" and then every
> word in the English lang which fit that pattern (for the above example:
> "every" fits).
> Does anyone know where such a table can be obtained?
If you want "hard copy" tables, there is a series of books published by
Aegean Park Press:
Pattern words - Three-letters to eight-letters in length
Pattern words - Nine-letters in length
Pattern words - Ten-letters and eleven-letters
Pattern words - Twelve-letters and greater
If you prefer software, there are pattern finders for several languages at:
http://ruby.und.nodak.edu/org/crypto/crypto/words/Pattern.lists/
Regards,
Dave
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 08:27:36 -0500
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> Dorina Lanza <[EMAIL PROTECTED]> wrote:
>> >R. Knauer wrote:
>> >
>> >> On Thu, 21 Jan 1999 13:26:52 -0500, Dorina Lanza <[EMAIL PROTECTED]>
>> >> wrote:
>> >>
>> >> >I think it's worse than this. The statement that the output of a filtered
>> >> >random source is non-random is false. If, for crypto purposes, we exclude
>> >> >pathological values such as zero from a TRNG we still have an equiprobable
>> >> >selection from a pool of possible values. The fact that the pool is slightly
>> >> >smaller does not reduce the randomness because the selection process is the
>> >> >same. The entropy would be slightly less, but not the independence of the
>> >> >samples.
>> >>
>> >> >This idea of post-processing contaminating the source is fallacious.
>> >>
>> >> What you have just said is completely incorrect for crypto-grade
>> >> random numbers.
>> >>
>> >> If you do what you have just proposed, you will be vulnerable to a
>> >> Bayesian Attack.
>> >
>> >No. The filtered key stream is not biased. Every entry in the pool is equally
>> >probable. The fact that the poll contains 2^N - 2 entries instead of 2^N entries
>> >does not create a vulnerability.
>> >
>> >Please indicate otherwise if you are able.
>>
>> The filtered keystream, treated as a set of all possible 2^N strings, is
>> biased. Since the possible plaintext is one of that set, you need to
>> do the stats over the entire set -- not only over the set of potential
>> keys.
>
>You are using the term "biased" in a manner with which I am not familiar. Bit bias
>would indicate a difference in the incidence of ones and zero.
Which is why I used the term 'bias' instead of the more specific 'bit bias.'
Bias is fairly easy to define -- non-equiprobability of all samples.
Bias comes in a lot of different forms....
>> Reductio ad absurdam -- instead of throwing out only 2 keys, throw out
>> K. If K == 2^N - 1, you have no security whatsoever. Please define
>> the maximum K at which you have "perfect security" and provide reasons
>> for your answer.
>>
>> -kitten
>>
>> (Hint : the minimum such K is zero.)
>
>OK. First, I think we agree that "perfect security" means maximum attacker effort per
>bit.
No, Shannon gave a very clear definition of "perfect security" that
doesn't mention maximum attacker effort at all. A cryptosystem is perfectly
secure if it isn't possible for an attacker to determine anything about
the message (other than its length).
The rest of the message flushed as being based on this fallacious definition.
-kitten
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator and Pentium III
Date: Mon, 25 Jan 1999 20:21:24 +0100
student wrote:
>
> Hi !
> I have few questions:
> 1. How secure are "random" numbers generated by measuring mouse
> movements or recording keystrokes ? Are they random enought to be used
> with OTP, when we want to protect data against the most resourcesfull
> enemy ? If not, why ? (If we want very random numbers we can collect a
> lot of less-random data in this way and produce small quantity of
> randomness-enougth numbers, so theoritically, we can reach any level of
> randomness.)
> 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.
I am not knowledgeable to be able to answer your questions. But
my follow-up in the thread of David Ross might have some tiny
relevance to the topic here.
M. K. Shen
------------------------------
From: student <[EMAIL PROTECTED]>
Subject: Random numbers generator and Pentium III
Date: Mon, 25 Jan 1999 18:44:18 +0100
Hi !
I have few questions:
1. How secure are "random" numbers generated by measuring mouse
movements or recording keystrokes ? Are they random enought to be used
with OTP, when we want to protect data against the most resourcesfull
enemy ? If not, why ? (If we want very random numbers we can collect a
lot of less-random data in this way and produce small quantity of
randomness-enougth numbers, so theoritically, we can reach any level of
randomness.)
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.
Thanks in advance
T.H. ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Alan DeKok)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 14:52:51 -0500
In article <[EMAIL PROTECTED]>,
Darren New <[EMAIL PROTECTED]> wrote:
>> A 'Cryptographically secure' RNG generates random numbers via a
>> *non-deterministic* algorithm. The output of any one generator is
>> unpredictable even knowing the algorithm and all initial conditions.
>
>Uh, excuse me? I'm afraid that if I know the RC4 algorithm and all
>initial conditions including the key, I can certainly predict exactly
>what will come out. That's why it's possible to encrypt something with
>RC4 and decrypt it later.
Then you're using RC4 as a stream cipher, not a PRNG.
>If it generated nondeterministic output (via a nondeterministic
>algorithm), I would have to save all its output somewhere in order to
>get it back again.
Yes, so? If you want a real RNG, you don't want anyone to be able
to get the output back again. (i.e. predict it's past or future
behaviour)
>I would think a 'cryptographically secure' RNG would have something to
>do with chaotic systems or cryptanalysis. But it's nothing to do with
>nondeterministic.
Chaotic systems have mostly been shown to be insecure.
> There are nondeterministic algorithms, but RC4 isn't one of them.
So? Did I ever say it was?
Personally, I wouldn't trust a deterministic 'cryptographically
secure' RNG. It's just too easy to guess initial or internal states.
You're much better off when *also* using input from external
non-predictable sources.
e.g. RC4 with random re-keying based on user input, mouse values, or
low bits of the system clock.
You won't be able to reproduce or predict the output, but that's
EXACTLY what you want for a CS-RNG.
Alan DeKok.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode
Date: Mon, 25 Jan 1999 20:37:36 +0100
[EMAIL PROTECTED] wrote:
>
> Ok, will. See also my posting here on Jan 5/99, RE "On leaving the 56-bit key
> length limitation" -- which also discusses some options in this line of
> reasoning, to increase the attacker's undecidability mulitiplied by the
> key-space while the intended recipient has 2^56 less options ;-)
See an earlier thread in this group initiated by me: 'On Living with
the 56-bit Key Length Restriction'. A revised version of the original
post is available at
http://www.stud.uni-muenchen.de/~mok-kong.shen/#paper17
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: All 8 modes, was Re: 3DES in EDE mode versus EEE mode
Date: Mon, 25 Jan 1999 18:43:39 GMT
In article <78ht1u$img$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <78dt09$s4p$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> >...
> > In this sense, it would be perhaps useful to consider an alternative 3-DES
> > Standard, where all 8 combinations (EEE, EED, DDE ... DDD) would be allowed
> > and *post-selected* by the sender, Bob, after algorithm negotiation (3-DES).
> > So, Alice would have the right key(s) from Bob (eg, send by AOEP-RSA), but
> > she would have to test the first DES block to see which scheme was randomly
> > chosen by Bob -- for which she may need to try out one block at most eight
> > times, to be sure. An attacker, however, would need to try out an average of
> > four blocks but each one with an average of half the corresponding
key-space,
> > for each possibility of one, two and three keys. Which would at least
> > multiply by 4x the average attack workload for 1-DES due to the combination
> > uncertainty of EEE .. DDD.
> >
> > Comments?
>
> Ed,
>
> Effectively you are adding 3 bits to the key. In the same spirit
> why use the tree DES keys in a fixed order?
Yes, sure -- there is no need to fix what can be tested rather quickly by the
intended recipient. This is the whole idea, let the attacker cope with the
diversity multiplied by the key-space.
>There are 6 possible
> permutations that can be used to further increase the
> "variability" of the cipher. For example, instead of
> E(K1)*D(K2)*E(K3) one might as well use D(K3)*D(K1)*E(K2). In all
> we have now 48 algorithmic variations that would depend on the
> secret key. Security cannot be lower and is probably higher. For
> example, resistance to a brute force attack has now increased
> if, say, the attacker knows K1.
>
> I think "variable" ciphers are a good idea because the secret key
> now effects not only the data flow but also the control flow in
> the cipher. See my post to sci.crypt dated 30.12.98 with subject
> "Security through obscurity in the smartcard world".
>
Ok, will. See also my posting here on Jan 5/99, RE "On leaving the 56-bit key
length limitation" -- which also discusses some options in this line of
reasoning, to increase the attacker's undecidability mulitiplied by the
key-space while the intended recipient has 2^56 less options ;-)
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Mon, 25 Jan 1999 20:11:33 +0100
David Ross wrote:
>
> How would you test the 'quality' of the generated random number
> stream?
There are tests for statistical quality, e.g. Maurer's universal
statistical test. I am ignorant of tests for crypto quality.
I guess the issue of cryptological strength is inherently fuzzy
and not entirely separable from subjectivity and concepts like
confidence intervals, i.e. no security can be claimed on an absolute
scale in practice. But experts might refute my un-knowledgeable
assertions.
M. K. Shen
------------------------------
** 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
******************************
