Cryptography-Digest Digest #230, Volume #13 Mon, 27 Nov 00 06:13:01 EST
Contents:
Re: hardware RNG's (David Schwartz)
Re: collision probability with file checksums ("bubba")
Re: Is Feistel Block Cipher With Known Key An All Or Nothing Transform? (John Savard)
Re: Effects of successful break - a "what if"-scenario? (John Savard)
Re: collision probability with file checksums (David Schwartz)
Re: Effects of successful break - a "what if"-scenario? (Bill Unruh)
Re: Data Encryption Standard ?? (Bill Unruh)
Re: collision probability with file checksums (wtshaw)
Re: Cyrptography Digest Archive ? ("Will Anthony")
Re: collision probability with file checksums ("Scott Fluhrer")
Re: Proof of posession (csbh@(THESE)datahit.com (Coridon Henshaw))
This place Pays out great and its FUN!!!! ([EMAIL PROTECTED])
Re: Data Encryption Standard ?? ("kihdip")
Re: [Question] Generation of random keys (Per Claesson)
P/w based authentication and key exchange (Per Claesson)
Re: Effects of successful break - a "what if"-scenario? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Sun, 26 Nov 2000 16:12:50 -0800
David Schwartz wrote:
>
> Dan Oetting wrote:
>
> > 3. [Statistics] of, pertaining to, or characterizing
> > a set of items every menber of which has an equal chance
> > of occurring with a particular frequency.
>
> This is a poor description of the statistical meaning. If this were
> correct, for example, no random distribution could have a mode. Every
> statistician I've ever known has used 'random' to describe distributions
> that were had a mode and a standard deviation. Heck, even gaussian
> distributions are described as random with respect to the values of
> individual members of a set whose distribution is described as gaussian.
>
> DS
By the way, I can cite dozens of usages if you'd like, for example
http://www.wku.edu/~neal/statistics/poisson.html
In each case, a distribution is described as 'random' despite all
possible values not having equal frequency.
DS
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Mon, 27 Nov 2000 01:09:40 GMT
If I understand the claim of SHA-1 correctly, finding a colliding file
would take as many attempts as guessing a 160-bit number. In other
words, it could take 2^160 tests worst case, or 2^159 average. So
even the ability to make 2^150 tests would require an enormous
amount of luck in addition. The ability to make 2^80 tests would be
useful only if you had 2^80 machines working in parallel.
"Ed L Cashin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello. A file integrity verification product like tripwire uses
> different algorithms to compute checksums for files. By comparing the
> checksums of a file with known state to the current file's checksums,
> it's possible to find out whether the file contents have been
> modified.
>
> If the system uses just one 160-bit algorithm, say SHA-1, for doing
> the checksums, then what are the chances that an intruder could make a
> malicious file that has the same checksum as the file's known-state
> checksum?
>
> I only have slightly old references at hand (Schneier 1996 and Menezes
> et al. 1997) for figuring out the numbers. Using numbers from the
> latter (Applied Handbook of Cryptography, p. 337), I'm trying to
> figure out how secure it is to use SHA-1 all by itself to detect file
> modification:
>
> 1) Attacker can do 2^80 brute-force tests
> 2) 160-bit digest requires 2^160 brute-force tests
> 3) Attack is infeasible by a long shot.
>
> ... does that hold up?
>
> --
> --Ed Cashin PGP public key:
> [EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is Feistel Block Cipher With Known Key An All Or Nothing Transform?
Date: Mon, 27 Nov 2000 01:18:34 GMT
On Sun, 26 Nov 2000 11:47:05 -0500, Gary <[EMAIL PROTECTED]>
wrote, in part:
>When a 'secure' Fesitel cipher is used on a block with a publicly known key
>and some of the resulting block is removed. Does the bita that have been
>removed have to be brute forced or is there a faster way?
If the Feistel block cipher really is secure, indeed there is no
relationship that can be exploited between the plaintext that lead to
ciphertexts with the same bits except for a few.
So there is not a faster way...but there is an exception.
Brute-forcing the removed bits will give you many possible plaintexts.
But how can you tell if they are correct? So you need to know
something about the plaintext, such as that it might consist of only
printable ASCII characters.
If the number of removed bits has more possibilities than the
plaintext, you could try all possible plaintexts more quickly.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Effects of successful break - a "what if"-scenario?
Date: Mon, 27 Nov 2000 01:21:07 GMT
On Sun, 26 Nov 2000 12:03:39 +0100, Ichinin <[EMAIL PROTECTED]> wrote, in
part:
>What would the possible reaction from the designer (or
>corporation), potential actions etc...?
Well, it certainly is possible that there might be a temptation to sue
for libel, to silence whoever found the flaw, or whatever.
However, an incontrovertible exhibition of the flaw, made widely
available as quickly as possible, would be a way to forestall that. I
would tend to think these possibilities are usually not to be worried
about, though, despite certain movies to the contrary.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Sun, 26 Nov 2000 17:37:06 -0800
Ed L Cashin wrote:
> If the system uses just one 160-bit algorithm, say SHA-1, for doing
> the checksums, then what are the chances that an intruder could make a
> malicious file that has the same checksum as the file's known-state
> checksum?
Consider that no collisions are known for either SHA-1 or MD5 (which
only uses a 128-bit checksum) and the odds of an intruder being able to
find a collision for a given checksum are as remote as can be. If an
attacker did find such a collision, the value of being the first to find
such a collision would probably exceed the value of breaking into your
machine. ;)
DS
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Effects of successful break - a "what if"-scenario?
Date: 27 Nov 2000 06:02:59 GMT
In <[EMAIL PROTECTED]> Ichinin <[EMAIL PROTECTED]> writes:
]I have a theoretical question.
]What if someone found an efficient way of finding a
]flaw in an algorithm that could reduce it's complexity
]from "requiring loads of time" to "searchable within
]hours".
The algorithm would no longer be used by any thinking people.
]What would the possible reaction from the designer (or
]corporation), potential actions etc...? The corporation
]may be boasting super secure encryption and the algorithm
]may be used in quite a few products.
Depends. Some would ignore you, relying on the ignorance and
lack of research of many buyers. Some would send out notices to all
users and offer and updated and more secure.
Microsoft at great fanfare introduced their new chap 80 algorithm (lanman) which
was shown by Schneier and others to be woefully weak. They then introduced a new
slightly better version, but still supported the old one, and some places still
used the old one.
]What is the common reaction in these cases, i mean *what*
]happens? Any such previous cases?
Common? They will differ depending on the company. What did Intel do
when it was shown that their processor made math errors? What did Tylenol
do when it was discovered someone had filled some capsules with cyanide?
What did Perrier do when gasoline was discovered in some of their bottles of
water? What did Exxon do when it was discovered that their tanker leaked when
driven onto a reef? What did Netscape do when their encryption was shown to be
breakable by a high school student? What did DECSS do when it was shown tht the
DVD "encryption" was woefully inadequate? .... Evey company is different.
]Just a theoretical question.
Not theoretical. It happens every day.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Data Encryption Standard ??
Date: 27 Nov 2000 06:05:13 GMT
In <jgfU5.1577$[EMAIL PROTECTED]> "Kidkay" <[EMAIL PROTECTED]> writes:
]Hello, I need to find as much information as possible on Data Encryption
]Standard. I need to know it's encryption strength, hardness of deciphering,
]resistance to hacker attacks, ease of development and implementation. I've
]been searching all over the net, but haven't found too much information on
]DES except on the RSA site. If someone recommend some books I can read or
]websites I can view; I'll appreciate it. I'm learning cryptology. Thank you
]in advance.
Bruce Schneier-- Applied Cryptography
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: collision probability with file checksums
Date: Sun, 26 Nov 2000 23:58:51 -0600
In article <[EMAIL PROTECTED]>, David Schwartz
<[EMAIL PROTECTED]> wrote:
> Ed L Cashin wrote:
>
> > If the system uses just one 160-bit algorithm, say SHA-1, for doing
> > the checksums, then what are the chances that an intruder could make a
> > malicious file that has the same checksum as the file's known-state
> > checksum?
>
> Consider that no collisions are known for either SHA-1 or MD5 (which
> only uses a 128-bit checksum) and the odds of an intruder being able to
> find a collision for a given checksum are as remote as can be. If an
> attacker did find such a collision, the value of being the first to find
> such a collision would probably exceed the value of breaking into your
> machine. ;)
>
> DS
Everybody is missing the obvious, to work the hash backwards, starting
with the hash and proceeding to possible inputs. Defining the possible
inductive results reveals how the hash can be manipulated upstream. It
may be a challenge to find how to do this effectively, but not trying
means not learning the trick. If the output of a hash is smaller than the
input, there are certain collisions.
--
Pangram: Move zingy, jinxed products; hawk benign quality fixes.
Another: Bold information superhighway vexs quizzical jocks.
------------------------------
From: "Will Anthony" <[EMAIL PROTECTED]>
Subject: Re: Cyrptography Digest Archive ?
Date: Sun, 26 Nov 2000 22:15:12 -0800
Why not write a program that takes the input of a short wave radio turned to
a dead frequency and hash the stellar noise out into a random string of
junk? I have read theories on this, but I have never seen it put to use. I
imagine that it (stellar noise) would be a great foundation for random
generators.
WA
> >
> <snip>
> >
> > One of the things that intrigues me is how _HARD_ it is to get a truly
> > random number out of a computer! Most people who do not know
> > cryptography would think that a computer would be the _PERFECT_ device
> > for something like that.
> >
> > I'm sure it has been asked before, and as I am only now d/ling the
> > archives and haven't had time to search them, does anyone recommend a
> > computer program to generate a truly (as possible) random number? Any
> > URL that you could point me to would be helpful.
>
> No computer program, on its own, can generate a truly random number.
>
> The Mersenne Twister makes a fair old attempt at it, but cannot succeed.
>
> If you want truly random numbers (or, rather, numbers that are random
> enough for cryptography), you need a non-deterministic process or, at
> least, something that might as well be non-deterministic - something an
> attacker can't reproduce.
>
> Some possible ways to get cryptographically reasonable randomness:
>
> o Toss a coin. (NOT on a computer! A real,
> physical coin.) That gives you one bit of
> entropy per toss. Record the results, and
> type them in.
>
> o Roll a die. (NOT on a computer! A real,
> physical die.) An eight-sided die,
> available from any good fantasy roleplaying
> store, will give you 3 bits of entropy
> per roll. Record the results, and type them in.
>
> o Hook up your computer to a lava lamp.
> (This has been done, by the way - A Web
> search may well reveal more information.)
>
> o Hook up your computer to a radioactive
> source. Careful...
>
> o On some (all?) Linux systems, /dev/random might
> be worth a look. This is probably the least good
> option from this list.
>
>
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Sun, 26 Nov 2000 22:47:39 -0800
wtshaw <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, David Schwartz
> <[EMAIL PROTECTED]> wrote:
>
> > Ed L Cashin wrote:
> >
> > > If the system uses just one 160-bit algorithm, say SHA-1, for doing
> > > the checksums, then what are the chances that an intruder could make a
> > > malicious file that has the same checksum as the file's known-state
> > > checksum?
> >
> > Consider that no collisions are known for either SHA-1 or MD5
(which
> > only uses a 128-bit checksum) and the odds of an intruder being able to
> > find a collision for a given checksum are as remote as can be. If an
> > attacker did find such a collision, the value of being the first to find
> > such a collision would probably exceed the value of breaking into your
> > machine. ;)
> >
> > DS
>
> Everybody is missing the obvious, to work the hash backwards, starting
> with the hash and proceeding to possible inputs. Defining the possible
> inductive results reveals how the hash can be manipulated upstream. It
> may be a challenge to find how to do this effectively, but not trying
> means not learning the trick. If the output of a hash is smaller than the
> input, there are certain collisions.
Why do you think that everyone missed it? One of the explicit design goals
of a secure hash function is the computational infeasability to, given one
file, create a different file that hashes to the same value, and attempting
to run the hash function backwards is an obvious way to do it. Hence, MD5
and SHA-1 were designed to attempt to make this infeasable. If you do find
a method of computing the inverse of the hash function, or finding such a
second file (or just find a single collision, or finding a preimage of, say,
the all-zero or all-ones output) with either MD5 or SHA-1, please publish
it.
--
poncho
------------------------------
Subject: Re: Proof of posession
From: csbh<REMOVE>@(THESE)datahit.com (Coridon Henshaw)
Date: Mon, 27 Nov 2000 06:58:39 GMT
[EMAIL PROTECTED] (Matt Timmermans) wrote in
<[EMAIL PROTECTED]>:
>The authority can send you the level 0 hash upon request. Given that,
>before downloading a file you can download and check all hash levels.
What's to stop the download site from returning known-good hash values
(i.e. lying) for files which contain completely different data?
--
Coridon Henshaw -- http://www3.sympatico.ca/gcircle/csbh
"..To expect a good deal from life is puerile." -- D.H. Lawrence
------------------------------
From: [EMAIL PROTECTED]
Subject: This place Pays out great and its FUN!!!!
Date: Mon, 27 Nov 2000 07:39:00 GMT
http://www.cashwars.com/r/sike3
begin 644 Cashwar.HTML
M/&$@:')E9CTB:'1T<#HO+W=W=RYC87-H=V%R<RYC;VTO<B]S:6ME,R(^/&EM
M9R!B;W)D97(](C$B('-R8STB:'1T<#HO+W=W=RYC87-H=V%R<RYC;VTO:6UA
M9V5S+V-W;&]G;V)L=64N9VEF(B!W:61T:#TB,3<U(B!H96EG:'0](C0X(CX\
#+V$^
`
end
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Re: Data Encryption Standard ??
Date: Mon, 27 Nov 2000 09:04:00 +0100
Chapter 7 of Handbook of Applied Cryptography could also be a place to look:
http://cacr.math.uwaterloo.ca/hac/
http://cacr.math.uwaterloo.ca/hac/about/chap7.pdf
and ofcourse the FIPS PUB 46-3:
http://www.itl.nist.gov/fipspubs/by-num.htm#FIPS_TOP
http://csrc.nist.gov/fips/fips46-3.pdf
Kim
"Kidkay" <[EMAIL PROTECTED]> wrote in message
news:jgfU5.1577$[EMAIL PROTECTED]...
> Hello, I need to find as much information as possible on Data Encryption
> Standard. I need to know it's encryption strength, hardness of
deciphering,
> resistance to hacker attacks, ease of development and implementation. I've
> been searching all over the net, but haven't found too much information on
> DES except on the RSA site. If someone recommend some books I can read or
> websites I can view; I'll appreciate it. I'm learning cryptology. Thank
you
> in advance.
>
>
> -Kidkay-
>
>
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Mon, 27 Nov 2000 10:48:06 +0100
Alan Rouse wrote:
>
> The original post on this thread was requesting source code to generate
> a random key. I've never seen source code that could flip a coin or
> roll dice.
I guess a PRNG could be used for this purpose? I searched for one
recently, and found Yarrow on www.counterpane.com (sorry, can't remember
exact url).
Regards,
volley
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: P/w based authentication and key exchange
Date: Mon, 27 Nov 2000 11:15:26 +0100
Looking for a protocol for password based authentication and key
exchange. Client and server are both automated, so passwords do not need
to be "human". :) I've looked at numerous protocols, and even though
many of them seem appropriate, I find it very difficult to discern their
relative advantages and disadvantages.
The two protocols, as far as I've gathered, that seem on top at the
moment are PAK and SRP. However, they also seem to be very new; are
there any time-tested protocols around? If not, would PAK or SRP do?
This is for a non-critical distributed hobby project; just implementing
the crypto part for fun and experience, just like I'm attempting
database replication and other stuff...
Best regards,
volley
Some of the URLs I visited:
SRP: http://www-cs-students.stanford.edu/~tjw/srp/
PAK: http://www.bell-labs.com/user/philmac/pak.html
http://www.IntegritySciences.com/links.html
http://grouper.ieee.org/groups/1363/StudyGroup/Passwd.html
http://theory.lcs.mit.edu/~rivest/crypto-security.html
...and of course the sci.crypto faq.
(My good old comp.sec. book mentions Diffie-Hellman. I loved that part
of the book, until they reached the part about man-in-the-middle
attacks. And then it merely states that "more advanced versions of DH
prevent this kind of attack", before moving on to another subject. I
guess I'm looking for the ultimate "more advanced version of DH". :o))
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Effects of successful break - a "what if"-scenario?
Date: Mon, 27 Nov 2000 12:00:57 +0100
Ichinin wrote:
>
> What if someone found an efficient way of finding a
> flaw in an algorithm that could reduce it's complexity
> from "requiring loads of time" to "searchable within
> hours".
One possibility that is not to be ignored is that he keeps
that knowledge for himself and tries to gain (big) profits.
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
******************************
