Cryptography-Digest Digest #57, Volume #9 Tue, 9 Feb 99 01:13:04 EST
Contents:
simple challenge protocol (Paul LeMahieu)
Re: Intel's description of the Pentium III serial number (Roger Carbol)
Re: What is left to invent? ("Douglas A. Gwyn")
Re: Spread Spectrum (wtshaw)
Re: Foiling 56-bit export limitations: example with 70-bit DES (wtshaw)
Re: *.EXE files Encryption ([EMAIL PROTECTED])
Re: simple challenge protocol (Thomas Wu)
Re: Historical basis for BLOWFISH ("karl malbrain")
Re: Recluse Creates Encryption-Based Imagery (Walter Eric Johnson)
Re: hardRandNumbGen (Terry Ritter)
Re: RNG Product Feature Poll (Terry Ritter)
Re: What is left to invent? (Terry Ritter)
Re: What is left to invent? (Terry Ritter)
Re: Threat Models: When You Can't Use a One-Time Pad (Walter Eric Johnson)
Re: RNG Product Feature Poll (Paul Crowley)
----------------------------------------------------------------------------
From: Paul LeMahieu <[EMAIL PROTECTED]>
Subject: simple challenge protocol
Date: Mon, 8 Feb 1999 17:10:15 -0800
Hi,
I'm writing some client-server code, and I'd like a simple
method for the server to verify that the command came from
a client having the correct password.
My requirements:
1) no clear-text passwords sent over the network
2) server only executes command if it was sent
by a client with the correct password
3) Model: hackers can look at the network, block packets,
send packets, spoof machine identities, etc.
I have a feeling the algorithm I'm about to describe is
very well known. It seems simple and safe, but I want to make sure
there's nothing obvious I'm missing.
Assumptions:
Both client and server know a password (secret key k),
and a good one-way hash f(k,data). Everything but k
is known by potential hackers.
Protocol:
1) Client sends command c to server.
2) Server creates challenge r (random number) and sends it to the client
3) Client responds with f(k,c+r)
4) Server compares the f(k,c+r) returned by the client with
a locally computed one. If they're the same, the server
executes the command c.
Is this as secure as it seems to me? I see only one shortcoming: the server
must store the clear-text password somewhere (storing a one-way encrypted version
won't do).
I welcome any comments on this protocol, as well as comments on the faith
I've placed in "a good one-way hash".
Thanks,
Paul LeMahieu
[EMAIL PROTECTED]
------------------------------
From: Roger Carbol <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Tue, 09 Feb 1999 01:26:56 GMT
Anthony Naggs wrote:
> Processor Serial Number
>
> [...]
>
> The lower 64 bits
> are different for each processor and have no independent meaning.
So what's serial about it, then? The numbers must be part of some
series if they are serial numbers.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
Date: Tue, 09 Feb 1999 02:18:41 GMT
Terry Ritter wrote:
> I would say that the only "provably secure" OTP is one for which we
> have a provably random source.
> But there *is* *no* PROVABLY random source.
That's not so; there are a variety of techniques for producing
truly random bit streams. For example, radioactive decay can
be used (with sufficient processing to ensure that any systematic
bias has been removed). Even thermal noise is utterly secure
against pattern analysis.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Spread Spectrum
Date: Thu, 28 Jan 1999 23:33:52 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On Thu, 28 Jan 1999 15:31:24 -0600, [EMAIL PROTECTED] (wtshaw) wrote:
>
> >In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> >
> >> Title is The Bug Book and publisher is
> >> Paladin Press in Boulder Colorado.
> >>
> >That sounds like an old title, in fact I believe that I have volumes 1, 2,
> >and 3, and it is about some early integrated circuits, not exactly what
> >you have in mind. It might be a good idea to check title archives or you
> >may be adding to someone's confusion.
>
> New edition of old book, but there never was more than one 'volume'.
> Just the original title.
Maybe I'm confusing it with something else, but this seems too familiar.
> >
> >About Spread Spectrum, it's a big subject...good luck.
>
> Yeah, and it appears that no one is able to provide the answers to the
> question about intercepting and converting DS back into speech...
Someone did give a URL. It all depends if you want the original speech
characteristics or will settle for something like good synthesized
speech. Taking digital to analog takes some smoothing integrator circuits
to knock the corners of of the stepped waves, so to speak. The oldest and
simplest way is with a series of parallel filters with darlington stages
to allow good recovery from the LC circuits.
> >--
> >A much too common philosophy:
> >It's no fun to have power....unless you can abuse it.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Thu, 28 Jan 1999 23:39:25 -0600
In article <78qr6s$4mj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
> > In article <78mv0l$oih$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> wrote:
> >
>
> > > 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.
> > >
> > You need not be hamstrung with simple ASCII as the source for your bits,
> > as you could generate them from something else than base 128, which is
> > about the poorest one to encrypt text directly from that there is.
> > -
>
> But, for DES, unicity can never be larger than 8 bytes -- one DES block --
> unless you use absolutely random bits, which would then be absolutely useless
> to send anything different than noise ...
>
You are still thinking in one linear dimension. It is the
multidimensional technique that I suggest that produces single blocks that
are closer to noise than to text, and this is what could force unicity to
be higher, that brute force will not result in a recognizable block with
one key alone.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: *.EXE files Encryption
Date: Tue, 09 Feb 1999 03:30:56 GMT
This isn't your worst problem.
Even if you find a way to say:
if (Correct()) LetThemIn();
else return;
I can crack your program by
changing a JNE instruction
to a JMP instruction and a few NOPs.
The reason this is a big problem is that
I'm *not* a good cracker, and anyone who
would think to look in notepad for the pwd
could probably also pull this stunt.
This isn't an easy problem to fix in general.
However,
one thing you might do would be make
2 exe files - a main one and a 'subroutine' one.
Encrypt the subroutine exe (before runtime).
During runtime decrypt it by the user's
entered pwd and then run it. If they got the wrong
password then they eat garbage ;-)
- Alex
On Mon, 08 Feb 1999 20:22:50 GMT, [EMAIL PROTECTED]
wrote:
>I am a beginning C programmer.
>and when I am making for example a program that requires the password to be
>entered, any one can easily see the password by examining the program in the
>notepad.
>
>Can anyone give me a piece of advice how to get rid of this problem?
>
>Thank'x.
>Alex.
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: simple challenge protocol
Date: 08 Feb 1999 18:27:19 -0800
Paul LeMahieu <[EMAIL PROTECTED]> writes:
>
> I'm writing some client-server code, and I'd like a simple
> method for the server to verify that the command came from
> a client having the correct password.
>
> My requirements:
>
> 1) no clear-text passwords sent over the network
> 2) server only executes command if it was sent
> by a client with the correct password
> 3) Model: hackers can look at the network, block packets,
> send packets, spoof machine identities, etc.
>
> I have a feeling the algorithm I'm about to describe is
> very well known. It seems simple and safe, but I want to make sure
> there's nothing obvious I'm missing.
>
> Assumptions:
>
> Both client and server know a password (secret key k),
> and a good one-way hash f(k,data). Everything but k
> is known by potential hackers.
>
> Protocol:
>
> 1) Client sends command c to server.
> 2) Server creates challenge r (random number) and sends it to the client
> 3) Client responds with f(k,c+r)
> 4) Server compares the f(k,c+r) returned by the client with
> a locally computed one. If they're the same, the server
> executes the command c.
There's the obvious dictionary attack against the password, and you've
already pointed out the "plaintext-equivalent" password problem below.
> Is this as secure as it seems to me? I see only one shortcoming: the server
> must store the clear-text password somewhere (storing a one-way encrypted version
> won't do).
>
> I welcome any comments on this protocol, as well as comments on the faith
> I've placed in "a good one-way hash".
This problem is, as you probably suspected, already solved. If you
don't mind both sides sharing the secret, use something like SPEKE
(http://world.std.com/~dpj/). For a protocol that enables the server
to store a password hash that can't be used to break into the system,
use SRP (http://srp.stanford.edu/srp/). All of these solutions
resist active and passive network attacks and require no symmetric
crypto.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "The pen may be mightier than the sword, but my
Phone: (650) 723-1565 mouse can crash Windows with one click."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Historical basis for BLOWFISH
Date: Mon, 8 Feb 1999 18:38:31 -0800
Bill Stewart <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
>If I remember correctly, wasn't there a problem with the
>C code implementation of Blowfish in either the 2nd edition book
>or in the software disks accompanying it?
Bill, POLITICS not-with-standing, you're going to have to re-base your
question. If you can DETERMINE errata (or other problems at large) as a
thing for understanding this thread, by all means <<offer up>>.
I'm looking, however, for evidence of design level mistakes vulnerable to
LINEAR analysis of key schedules, as was the case with REDOC II & III.
N.B. I've since tried to merge this thread with the earlier <<Q:
Differential analysis of BLOWFISH>>
Thanks, Karl M
------------------------------
From: [EMAIL PROTECTED] (Walter Eric Johnson)
Subject: Re: Recluse Creates Encryption-Based Imagery
Date: 9 Feb 1999 03:54:19 GMT
JarryLaw ([EMAIL PROTECTED]) wrote:
: On the other side of the coin, it
: looks as though Mr. Johnson may
: indeed be "seaching newsgroups for
: off-topic posts" to complain about.
: (In my view, a much more insidious
: habit).
Nonsense. I do not search newsgroups for off-topic posts
to complain about. In fact, except for spam, I rarely
complain about off topic posts.
Eric Johnson
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: hardRandNumbGen
Date: Tue, 09 Feb 1999 04:06:24 GMT
On Mon, 08 Feb 1999 20:54:11 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (R. Knauer) wrote:
>On Mon, 08 Feb 1999 19:28:59 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>This may be combining two concerns: first to acquire the uniqueness
>>which exists in expression, and second to prevent the identification
>>of the presumably known source text. The second we can achieve by
>>throwing away information, and the first is best achieved by using the
>>larger character representation, and not just the lsb's.
>
>I do not understand what you have just said wrt the LSB's. Why would
>using larger character representations be preferably to using LSBs?
There is simply more information present in all the bits than in just
the LSB. This allows us to throw away more in the hashing.
By using only LSB's, we throw away the rest of each character. But
this is information which is not well mixed. So we may be throwing
away bits which are more variable -- and thus more valuable -- than
the lsb's.
Even when characters have an overall "entropy" of less than a bit,
there is no particular reason to expect to find the entropy
concentrated in the LSB's. The LSB represents part of the coding; it
has nothing to do with the entropy transported by the variation in
usage of that coding.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: RNG Product Feature Poll
Date: Wed, 03 Feb 1999 08:15:10 GMT
On Tue, 02 Feb 1999 08:09:53 -0600, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Dan S. Camper) wrote:
>[...]
>I also thought it was common knowledge, like the bit selection method used
>in HotBits. It is indeed ironic that there is a patent on the method.
>
>I've briefly scanned the patent as found on the IBM Patent Search server
>and, without examining every single detail, I think out device would be in
>violation of the patent if implemented with the current algorithm. There
>go some more engineering dollars....
>
>Is there another public domain method for generating chunks of random
>numbers using a setup like this, besides the HotBits method?
Allow me to suggest simply measuring and reporting the time between
pulses. Unfortunately, this is a different architecture and implies
bandwidth to the computer which you may not have.
The counter time-base need not be very accurate, but we probably do
want 16 bits or more of precision in the counter. We expect the
counts to be Poisson, which is not flat. But we may be able to get
flat results simply by dropping enough counts into a CRC hash.
The good part of this is that we can simultaneously collect statistics
on the count values and so continuously evaluate and validate the
generator.
And if we don't like the CRC approach, we can discard every other
value, and then compare the remaining values by pairs to get a single
bit for every 4 count values, which is the HotBits method.
Note that we get all of this from the same count stream.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: What is left to invent?
Date: Tue, 09 Feb 1999 04:07:13 GMT
On Tue, 09 Feb 1999 02:18:41 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>> I would say that the only "provably secure" OTP is one for which we
>> have a provably random source.
>> But there *is* *no* PROVABLY random source.
>
>That's not so;
That *is* so.
>there are a variety of techniques for producing
>truly random bit streams.
There are techniques for *hopefully* "producing truly random bit
streams." There are no techniques for producing PROVABLY random bit
streams.
>For example, radioactive decay can
>be used (with sufficient processing to ensure that any systematic
>bias has been removed).
And here, of course, we are to *assume* that "sufficient" processing
has occurred. But assumption is not PROOF. Nor is the simple use of
a supposedly random process equivalent to PROVING that our machine has
properly sensed that process, that there is no interference, and that
we detect every event we should.
>Even thermal noise is utterly secure
>against pattern analysis.
Indeed, I think thermal noise in resistance (Johnson noise) is one of
the better sources. The shot noise from reverse-biased semiconductor
junctions in breakdown has somewhat more energy, and is even more
convenient. I think both of these can be just as secure in practice
as a radioactive source.
But the discussion was not about "pattern analysis," which would be
"security in practice." The discussion was about ABSOLUTE PROOF of
security due to a PROVABLY random source; this is simply not
available.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: What is left to invent?
Date: Tue, 09 Feb 1999 04:05:28 GMT
On Mon, 08 Feb 1999 20:47:06 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (R. Knauer) wrote:
>On Mon, 08 Feb 1999 19:28:05 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>[...]
>>The PROVABLY secure OTP is a goal, a dream, a theory -- which can only
>>PROVABLY protect theoretical data.
>
>What if I generated a pad by flipping a perfectly symmetric coin - one
>machined to high precision with the same amount of scant markings on
>each face to indicate 1 or 0? Wouldn't the sequence I generated with
>that coin be proveably random?
I would say not. But I would be glad to listen to what you consider a
proof.
Here you start with the assumption that the coin is machined "to high
precision," which immediately begs the questions: "*How* high is this
precision?" and: "Is that high enough?"
I think it is reasonable to make assumptions for practical use. We
might well construct a statistical argument which says that a coin of
a certain weight and construction, given a potentially-knowable
initial spin, will collect sufficient "randomness" from air currents
after a sufficiently long fall, so that the spin is no longer
"sufficiently" known. But even if we go through a detailed analysis,
these assumptions *will* be assumptions. They are still not proof.
We also need to distinguish the more conventional argument that "no
human could possibly spin a coin so that it will fall (with good
probability) on a particular side." It is true that I know of no
human who can do that. But it is also true that I know of no
theoretical argument (other than the unquantified air randomness,
above) which would prevent attaining such skill.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Walter Eric Johnson)
Subject: Re: Threat Models: When You Can't Use a One-Time Pad
Date: 9 Feb 1999 04:34:02 GMT
[EMAIL PROTECTED] wrote:
: Case 2 Encrypted OTP If you encrypt an OTP with say 56 bit DES. You'll have
: to do a brute 56 bit DES XOR every result with a sample encrypted message,
: sliding it bit by bit till you get the suspects. If the encrypted OTP is
: replaced as its used it could very difficult if the current starting point is
: unknown.
I'm a bit puzzled about why you would want to encrypt a one time pad
with anything. If you are in a situation where you need to encrypt a
one time pad, you should probably be using a different encryption
method to begin with.
Eric Johnson
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: RNG Product Feature Poll
Date: 3 Feb 1999 08:01:03 -0000
[EMAIL PROTECTED] (Dan S. Camper) writes:
> Is there another public domain method for generating chunks of random
> numbers using a setup like this, besides the HotBits method?
The Right Way to do randomness, as I understand it, is to get your
device to produce output as raw as possible and use that output to
drive a CPRNG. So you're best off making the counter as big (in
bytes) and as fast as you can, getting your device to send the counter
values directly rather than XORing them together, and resetting the
counter after each hit. The output from the counter will then be
seriously biased, but it will have the highest absolute information
output.
I'd then feed this into something like Counterpane's Yarrow, which is
released under some sort of liberal license, and get actual random
numbers out the other end. Or you could use a CPRNG like Panama which
has a "push" operation for adding entropy to the state. If export
controls are a concern there are (slightly slower) RNGs based on hash
functions with the same property - Linux's /dev/random is one of
these.
Under some circumstances you might still need an "entropyometer" that
measure when the CPRNG has been sufficiently seeded by the true RNG to
start generating useful random bits.
As far as I can tell this avoids the claims of the patent. If you use
more than one source than tag each timing block with information about
which source it came from - the aim is to make sure that no two
differentiable sequence of events can result in the same input to the
CPRNG, and therefore that you're getting the most value for money from
your randomness.
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
------------------------------
** 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
******************************
