Cryptography-Digest Digest #949, Volume #8 Fri, 22 Jan 99 16:13:04 EST
Contents:
Re: Metaphysics Of Randomness (R. Knauer)
Re: Nomadic Authentication (Medical Electronics Lab)
Re: Help: Which secret key cipher? (John Savard)
Re: Help: Which secret key cipher? (John Savard)
Re: Pentium III... ([EMAIL PROTECTED])
Re: Pentium III... (wtshaw)
Re: Random numbers for C: The END? (Terry Ritter)
Re: Metaphysics Of Randomness (Darren New)
Re: Who will win in AES contest ?? ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 18:14:06 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 11:28:39 -0500, Dorina Lanza <[EMAIL PROTECTED]>
wrote:
>Perhaps every message should look like a false one.
>I.e., every plaintext should be enciphered not so it looked like garbage, but that
>it looked like a letter from long lost Aunt Jane. This could be implemented by
>defining a search path through the available OTP pad space. Given a plaintext one
>searches for an appropriately formatted ciphertext. Is this less secure that
>plain-in-garbage-out? Not that I can see.
>
>The above description is silly not because it would be ridiculously slow, but
>because every message would need a prefix of the form "pad number N" to enable the
>receiver to recover the original message. The width of the pad number is of the
>same size as the length of the entire message *space*. So the prefix size would
>exceed the size of the actual cipher text. But it would be secure. (Let's see,
>it's provable, obscure, and inefficient; best of all worlds!)
If you XORed the message with the Aunt Jane text, you would generate a
key to send that key thru a secure channel, then the Aunt Jane cipher
could be decrypted on the other end.
But this system is vulnerable - the key has been generated from mixing
two text streams which results in a poorly constructed key for the OTP
cryptosystem.
If a secure OTP could be generated from the XOR of two text streams,
who needs a TRNG?
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Nomadic Authentication
Date: Fri, 22 Jan 1999 12:32:48 -0600
James Pate Williams, Jr. wrote:
>
> What authentication protocol(s) would be useful in a nomadic (mobile)
> networking environment? Ideally, the protocol would have to be
> resistent to replay attacks and would require a minimum number of
> exchanges.
check out the original MQV protocol. Along with each sides public
key, both sides generate a one time "ephemeral" public key too. The
combination generates a shared secret that also authenticates each
side to the other. As long as the permenent public keys are initially
verified out of band the protocol is pretty damn good.
Note that the IEEE p1363 (draft) standard presently uses a modified
version of the original MQV description. A lot of argument took
place on the p1363 listserve a while back. The only thing I gleaned
from that was that the original satisfied everyone, but there were
a few people who didn't like what they ended up with.
Only two exchanges are required, one from each side for the ephemeral
keys. You could send the permenent keys too if needed, but for good
authentication that shouldn't be necessary.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 20:22:20 GMT
Graham Jones <[EMAIL PROTECTED]> wrote, in part:
>I plan to encrypt and send a single message using a shared secret key
>scheme. I do not intend to send subsequent messages using this scheme.
>Could someone please point out to me the advantages of using a block
>cipher such as DES, over a simple algorithm such as an exclusive-or of
>the plaintext against the key. Note that the key length can be equal to
>the length of the plaintext.
>I realise that by using the XOR technique, the key can easily be
>recovered once the plaintext is known, but I'm not concerned about this
>in a one-shot situation.
>Also, I have little concern over the speed at which an XOR can be
>performed in comparison to DES. The application of the message involves
>a lengthy checking process; hence if an attack involved the trial of
>each key combination, then the time taken to check each recovered
>message would far outweigh the duration of each decryption pass.
>Any advise would be very much appreciated.
Headers trimmed, since I am incapable of replying in Dutch.
If you just want to send *one* message,
and you can arrange to have a secret key with your recipient in
advance,
then using XOR for a one-time-pad is adequate...
and if the time required to use a cipher like DES is not a concern
either,
then having a shorter secret key might well be more convenient, and,
although I would recommend triple-DES for adequate security,
your situation is one in which any secure cipher would be adequate,
and hence little advice is needed.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help: Which secret key cipher?
Date: Fri, 22 Jan 1999 20:29:10 GMT
Graham Jones <[EMAIL PROTECTED]> wrote, in part:
>BTW, I forgot to add: The message I wish to encrypt contains only raw,
>'formless' data i.e. not subject to structural analysis as, for
>instance, the text of a particular spoken language would be.
If this were actually true (I suspect that it may merely *appear* to
be true, and not really be as true as you think) then the condition
that the cipher used be secure no longer applies.
You could use, say, the combination of a monalphabetic substitution
and a simple columnar transposition, and there would be nothing on
which to base cryptanalysis! Or perhaps Vigenere. That would cover up
your data, and that would be all that's needed - if it offered no
openings to attack.
Truly, your situation means you are in absolutely no need of advice,
and can safely encrypt your message in almost any old way!
Hence, your post is quite a change from the usual queries asking for
help, where we are often forced to tell people that they are asking
how to do something that is impossible.
Since I'm doubtful your data is really formless - it may have
structures that are less obvious - I would still tend to advise that
you do use a secure method of encryption. But you have literally
specified, in your query, every condition that removes difficulty from
the problem of choosing an encryption method.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 20:19:47 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Fri, 22 Jan 1999 01:15:31 GMT, [EMAIL PROTECTED] wrote:
>
> >Yes, I believe it's possible to generate very high quality random numbers,
> >without thermal noise hardware, like Intel is planning to add to the Pentium
> >III. Random number generators are used for key generation.
>
> That very well may be true if you do not require crypto-grade random
> numbers.
>
> >I have quite a lot of experience in this specific issue. I've written about
> >five generations of cryptographic random number generators for assorted
> >applications on Intel machines. The latest generation I believe makes
> >extreemly high quality random numbers.
>
> Please elaborate.
Earlier generations were for projects that supplied crypto support on a number
of Internet products (like web servers). For interactive apps, collecting bits
from mouse position delta's was used.
The latest generation was used on some credit card processing software. Three
algorithms were available, with randomness analysis done to dynamically
select which algorithm to use. Randomness analysis would also flag that the
RND seemed broken, possibly halting the application.
The three algorithms included:
1) clock skew bit generator
Basically spin the processor incrementing a memory location (at like 200
million increments/sec) and then periodically (from a different clock source)
interrupt the processor and extract a single bit from the count. Repeat this
for as many bits as needed. Production rate as high as 1000 bits/sec can be
achieved. Unless the processor code path, cache hits, bus wait states, etc.
between each bit sample is identical, the bit will not be predictable. Also
the small jitter in the two clock sources will cause the relationship between
them to jitter, causing the sample value to vary. Typical clock crystals are
I believe +/- 25 ppm.
2) sound card noise collection
Collect a bunch of samples from the input (line/mic) of a sound card, and then
stir the bits together with a MD5. Production rate is a bit lower and also no
guarantee of a sound card. Also requires exclusve device use. Still, for a
secure server, requiring a sound card (cheaper is better) is not much of an
expense. Most PC already have sounds card now.
3) time variations in physical disk seeks
Perform a large number of physical disk seeks and measure processor clock
resolution timing using RDTSC (currently about 3 nanosecond resolution). Use
the bottom bit as part of random stream (or stir with MD5). Production rate is
slow (50-100 bits/sec), and makes your system noisy for a bit. For reseeding a
PRNG at periodic intervals this is not an problem.
Combined, these methods allow production of very high quality random numbers.
Nearly every currently existing PC can do these with no new processor. These
assume you retain physical security of the machine, which I think is pretty
realistic at the moment of key generation.
If course all these methods are meaningless if an intruder is allowed access
to modify the software.
The same weakness applies to a RNG in a processor. If the processor did the
whole private key generation, and kept it stashed in the processor (on
eeprom), with interfaces to run the crypto algorithms in the processor
(basically a smart card in your Pentium III), then I could see some improved
security. I don't believe this is what was announced by Intel though.
> To date no one has come up with a proveably secure method other than a
> hardware TRNG - although some have claimed their methods are
> practically secure to a very close level of approximation. The
> criterion is to produce an OTP cipher system which can withstand a
> Bayesian attack, yet not require distribution of the pads.
Some of the methods I described in essense are hardware RNG's. For example the
disk seek timing is influenced by micro air currents inside the drive case and
also temperature variations.
Things to consider include, is the random number predictable and can it be
influenced. PSNR's are totally predictable, if you know the algorithm and and
get in sync with the stream (not an easy task). I believe the methods I
described above are not very predictable, but without physical security, might
be influenced (by the NSA with some very significant effort). Even if they
could totally be influenced under lab conditions, this would have no effect on
the quality of private keys already generated.
My guess is none of the methods, including a Pentium III RND, are guaranteed
to pass Tempest security. I could imagine the RFI from the Pentium III RNG
might give away clues about it's value, as would the disk drive firmware. I'm
not a Tempest hardware or Pentium III designer, so can't say for sure.
If I were REALLY serious about security, I'd probably want some sort of RFI
protected, physically secure, crypto coprocessor with it's own eeprom storage
of my private keys. A $25 crypto iButton fits this description better than
some new instructions on a Pentium III.
- Jan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Pentium III...
Date: Fri, 22 Jan 1999 12:17:00 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> You would think the industry learned its lesson from the old days of
> closed architectures, key-based S/W, dongle keys, etc. I can just see
> Ziff Davis refusing to test anything that is Pentium III based.
>
Sometimes one must think in an obtuse way to see what one should be
looking out for. If some vital part of a computer, say the bios in a new
package that one just "had to have" also contained the internal battery to
sustain it, a serial number could be installed at the same time the
battery was purchased. I suppose one could simply add a switch of some
sort to go between several such chips. Then, buried deep in the system, a
check might be added to verify that a registered bios was installed....
Embedded id's are just another step in an endless series of trumphs and
overtrumphs to put security on yours or someone else's terms.
--
A much to common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.math.num-analysis
Subject: Re: Random numbers for C: The END?
Date: Fri, 22 Jan 1999 18:46:13 GMT
On 21 Jan 99 05:09:33 GMT, in <[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] () wrote:
>[...]
>I am honored to see a post by one of the co-inventors of the famed
>MacLaren-Marsaglia random number generator. Although, due partly to a
>Cryptologia article, that generator has generally been dismissed as a
>component of a cryptosecure stream cipher, I've tended to feel:
>
>1) the article was flawed, since one would never, in practice, use more
>than a few of the most significant bits of generated random numbers for
>stream cipher purposes, and
There were two formal articles, the first of which was a complete,
fully-exposed attack on a real encryption system using
MacLaren-Marsaglia:
1. Retter, C. 1984. Cryptanalysis of a MacLaren-Marsaglia System.
Cryptologia. 8(2): 97-108.
The next article addressed the question of the extent to which M-M
combining provides strength to the combined generators:
2. Retter, C. 1985. A Key-Search Attack on MacLaren-Marsaglia
Systems. Cryptologia. 9(2): 114-130.
There were also comments in letters:
3. Letters to the Editor. 1984. Cryptologia. 8(4): 374-378.
>2) more elaborate variations on the principle, using the basic
>MacLaren-Marsaglia generator as a building block, are possible.
Anything is possible. But, by itself, MacLaren-Marsaglia is simply
not a mechanism with significant cryptographic strength.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 20:50:24 GMT
> Yes, really. A DTM that has an RNG input grafted on can take transitions
> based on the RNG input.
> [...] In an NDTM, the set of available
> transitions is purely a function of current state and current tape
> symbol. You don't get to disallow certain transitions based on tape
> content not currently under the read/write head.
So where does the RNG get plugged into the DTM to make it an NDTM?
> Oracles for the halting problem tend to be difficult to realize.
That's why they're called Oracles. ;-)
BTW, your posting software is mixing up the followup-to field with
either the message-id or references field.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Date: Fri, 22 Jan 1999 17:59:56 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Coen L.S. Visser wrote:
> >
> > Brad Aisa <[EMAIL PROTECTED]> writes:
>
> > >Duh. If it can break it, then so can others. The U.S. govt doesn't have
> > >a monopoly on bright cryptanalysts.
> >
> > But at this point in time they may have the largest crypto
> > organization. I wouldn't know any other government, academic
> > or commercial organization that could measure up against the NSA.
> > Maybe there is something in China the general public doesn't know about.
>
> Besides the human resources, computing resources are also important.
> That's way there are export regulations on super computers
> and restrictions on nationality of people who are allowed to use
> such computers that are installed in friendly nations. It may be
> interesting to know also that there is (maybe no longer, I don't know)
> export restriction on software assisting proofs of mathematical
> theorems.
>
> M. K. Shen
>
True computing resources are an important part. But I assume
that all the millions the Red Chinese have given the Clinton
people has gone a very long way to loosen what ever controls
the Sate Department had to help slow the flow of advanced
computer technology to the Reds.
I wonder if the Senate is looking into this area or is
it off limits.
David A. Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= 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: Metaphysics Of Randomness
Date: Fri, 22 Jan 1999 18:52:50 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 22 Jan 1999 11:31:27 -0500, Dorina Lanza <[EMAIL PROTECTED]>
wrote:
>No. The filtered key stream is not biased. Every entry in the pool is equally
>probable.
A TRNG must be capable of generating all possible sequences of a given
length, as well as each of them being equiprobable. A filtered pool
does not meet the first criterion, even though it meets the second.
>he fact that the poll contains 2^N - 2 entries instead of 2^N entries
>does not create a vulnerability.
I fully agree. I am an advocate of using the two pathological
sequences, 000...0 and 111...1, as diagnostics for a broken TRNG,
since both are symptomatic of the two most common failiure modes - an
shorted output and an open output respectively.
But when you start filtering for such conditions as bit bias or other
statistical conditions, then you are distrubing the distribution in a
way that could lead to vulnerability.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
** 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
******************************
