Cryptography-Digest Digest #432, Volume #10 Tue, 19 Oct 99 15:13:04 EDT
Contents:
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: He is back...new "improved" code ("Crack This")
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: Amazon.com Crypto contest (John Savard)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
Re: Strengthening passwords against dictionary attacks (Anssi Bragge)
Re: Math explaination of RSA public-key? (Anssi Bragge)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible
([EMAIL PROTECTED])
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bob
Silverman)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terje
Mathisen)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible
([EMAIL PROTECTED])
Re: detecting backdoor in prime generator (Jerry Coffin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Tue, 19 Oct 1999 14:39:23 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
>
> > 3. Throw away the last N bits of salt. If 16 bits are thrown away,
> > 32768 hashes must be computed on the average to check a password.
> > Timing tests with the fastest available password checker would give
a
> > practical value for N.
>
> Allow me a question of ignorance. I assume that the hashed values
> of the correct passwords are stored. If you hash with a given constant
> salt (for all users), then there appears to be no value and no means
> of discarding N bits, for the salt is known, I presume. Isn't it
> that you append a given salt with N random bits and after hashing
> forget the N random bits? Thanks in advance.
>
> M. K. Shen
>
You have the gist of it.
stored password hash = HASH(password + salt + random bits)
I was including the random bits with the salt but that need not be the
case. The salt can be known but the random bits are unknown to
everyone.
The salt should be different for each user BTW. Large salt prevents an
attacker from building a complete hash dictionary off line.
If the salt is huge and has N bits then the number of different possible
hashes is
number of words in dictionary * 2^N
If this number is in the billions of terra bytes, no attacker can mount
and off line attack on all the combinations. My value of 2^1024 is
massive overkill but bits are cheap.
The random bits slow down the verification for each password. If the
verification takes a few seconds each then an exhuastive dictionary
attack becomes infeasible.
A previous poster pointed out that even when the correct hash is found,
all the random values should be check to avoid a timing attack. Clever
idea!
Additionally, by forcing the user to pick a password in with 16 or more
chars over possible set of 75 chars, exhaustive search become quite time
consuming.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Crack This" <[EMAIL PROTECTED]>
Subject: Re: He is back...new "improved" code
Date: Tue, 19 Oct 1999 09:46:22 -0500
Don't know...I told him good bye :-) I could not solve his ciphertext given
only the amount he gave me. It could be anything from simple substitution
to something much more complex.
Belldandy <[EMAIL PROTECTED]> wrote in message
news:7ufvqn$inr$[EMAIL PROTECTED]...
>
> Dan Day <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > Given that Mr. Fogelberg's friend is clearly still in the cryptographic
> > infancy, it seems likely to me that he would have used an
easy-to-remember
> > passphrase, and not one that would be so unmemorizeable that he would
> > have to store it in the computer. For that matter, since he was
> > issuing the encrypted message as a challenge, it's possible that he
> > didn't even bother to try to remember the passphrase after he
> > generated the ciphertext, since he had no interest in actually
> > being able to decrypt it himself.
>
> ..this might sounds silly but..... have you asked him whether his
encryption
> is... decryptable? I mean, for all combination of plain text, will his
> encryption will definitely decryptable?
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Tue, 19 Oct 1999 14:45:31 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> You can automat the server side, there is no problem for that.
> The only thing that SPEKE demands is that both entities share
> a little secret (a password...).
>
> A stand alone NT box can serve as a verifier in a in the SPEKE
> protocol, there isn't any reason why it couldn't....
>
>
Where will the server store the 'little secret'? The only way I know of
doing this is creating an ecrypted password file on the server. If an
opponent can gain access to the password file, a dictionary attack could
be mounted against the file. Thus I still contend that SPEKE or it's
variants do not cure the problem. SPEKE is great when two -people- are
interacting however.
--Matthew
[EMAIL PROTECTED] wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Thomas Wu <[EMAIL PROTECTED]> wrote:
> > > Tom St Denis <[EMAIL PROTECTED]> writes:
> > > >
> > ...
> > > > Simple as that.
> > >
> > > This is vulnerable to dictionary attack [attacker gets R and a,
> > > and tries passwords P until a == HASH(R + P)]. Any login system
> > > should work like SRP, SPEKE, or EKE to prevent a dictionary
attack.
> > > --
> > > Tom Wu * finger -l [EMAIL PROTECTED]
for
> >
> > ...
> >
> > SPEKE at least won't work for a non-interactive scenario. For
> > example, I am logging into a stand alone NT box. SPEKE requires
> > two active participants per the paper 'Strong Password-Only
> > Authenticated Key Exchange' by David Jablon. In my example, the
> > password must be authenicated from some file on the NT hard drive.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Amazon.com Crypto contest
Date: Tue, 19 Oct 1999 15:06:51 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>Does anyone know why residents of Quebec are excluded?
Quebec has a provincial law which regulates contests, and the
requirements of that law may be expensive to meet.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 15:13:57 GMT
On Tue, 19 Oct 1999 09:52:59 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>On the other hand, you (and some of the one-standard advocates)
>confound the issue. It is not whether one 'can' or 'cannot' use more
>than one AES candidates (unless a crypto law forbids that). One just
>wants NIST, for whose opinion one has a fair amount of respect, to
>testify that besides the AES winner, which is considered the best,
>a couple of others are also o.k., so that the question of doubt of
>strength of these (in case people want to use them e.g. in multiple
>encryption for whatever reason) is greatly reduced in magnitude.
If this is all you want, I have no problem with it. NIST can choose
an AES winner, and say that the other two (or three, or four) are also
okay. I don't mind. What I want to avoid is having multiple
algorithms in the AES standard, which would require a system to
implement multiple algorithms in order to implement the standard. I
also want to avoid forcing the user to make a choice: having the
standard be A or B. (As I have said, if we cannot make a decision how
to we expect non-cryptographers to.) I am perfectly happy with
secondary algorithms, or runners up, or anything like that.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Anssi Bragge <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: 19 Oct 1999 17:11:18 +0200
[EMAIL PROTECTED] (Bill Unruh) writes:
> Is it better than clear text password? yes, except for storage of cler
> text passwords. But one can do better.
Like: Server sends server random SR.
Client sends UserId, H1( H2(password) || SR || CR ), CR.
Server sends H1( H2 || CR ) to acknowledge success
OR H1( rand ) to fail.
? (Some kind of Challenge-Response Test)
Or is it dangerous to let Eve to know both H1(H2SRCR) and H1(H2CR)?
H2 is never published, but hashes including H2 catenated with 2
different additions are. Still, when H1 & H2 are normal today safe
considered hashes, this shouldn't give too much material for analysis.
abe
--
Anssi Bragge
UBS AG http://www.ubs.com/
Bahnhofstrasse 45, CH-8098 Zuerich, Switzerland
Tel: +41 1 236 0485 / Fax: +41-1-236 41 41 / GSM: +41-76-388 7722
------------------------------
From: Anssi Bragge <[EMAIL PROTECTED]>
Subject: Re: Math explaination of RSA public-key?
Date: 19 Oct 1999 17:18:07 +0200
[EMAIL PROTECTED] (Bill Unruh) writes:
> Message= 25
> C= 25^17%77=9
> M=9^53 %77 =25
Well, yes, but the problem arises when the numbers get huge,
one needs Big Number capable libraries.
And I haven't actually ever encrypted any message by hand like
this. So, when encoding (say,) a string, does one take the
hex-representation of the message (char, or whichever) per time to do
the math, or are some concatenation methods used? I'd say the numbers
do get too high when trying too large message values.
abe
--
Anssi Bragge
UBS AG http://www.ubs.com/
Bahnhofstrasse 45, CH-8045 Zuerich, Switzerland
Tel: +41 1 236 0485 / Fax: +41-1-236 41 41 / GSM: +41-76-388 7722
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 15:20:17 GMT
In article <[EMAIL PROTECTED]>,
"Thomas J. Boschloo" <[EMAIL PROTECTED]> wrote:
> Bruce Schneier wrote:
> >
> snip
> >
> > Some have dealt with this problem by requiring stronger and stronger
> > passwords, but that is no longer effective. Over the past several
> > decades, Moore's law has made it possible to brute-force larger and
> > larger entropy keys. At the same time, there is a maximum to the
> > entropy that the average computer user (or even the above-average
> > computer user) is willing to remember. You can't expect him to
> > memorize a 32-character random hexadecimal string, but that's what
has
> > to happen if he is to memorize a 128-bit key. These two numbers
have
> > crossed; password crackers can now break anything that you can
> > reasonably expect a user to memorize. Good passwords are difficult
to
> > memorize, he will complain, but this difficulty is precisely why
they
> > are considered good.
>
> This is why, if I ever wrote an encryption product, I would let it
brute
> force like 20 bits in surplus to the entered pass phrase. [700 Mhz * 2
> seconds / 2000 operations a try = 20 bits]. Like in
>
http://www.research.digital.com/SRC/personal/Martin_Abadi/Papers/pwd-rev
ised/pwd-revised.html!
>
> It's not much, but it beats the entropy of the 32 bits of the six
> character user password. If computers get closer to the limits
enforced
> upon their speed by the laws of nature, this figure will get better.
>
> Highest respect,
> Thomas J. Boschloo
> --
> Cheaper than Intel: AMD K6-2 3Dnow 500 Mhz
> Faster than Intel: AMD K7 Athlon 700 Mhz
> More privacy than Intel: <http://www.bigbrotherinside.com/#help>
> PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
> Email: boschloo_at_multiweb_dot_nl
>
>
Thomas,
I had exactly the same idea as is presented in the above paper. Looks
like they beat me by a few years however.
See the thread "Strengthing passwords against dictionary attack"
I wonder if any systems are currently using this idea?
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Tue, 19 Oct 1999 15:49:38 GMT
In article <7ucue1$3ej$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Strengthening passwords against dictionary attacks
>
It looks like someone already had this idea! At least, I am on the
right track :-)
http://www.research.digital.com/SRC/personal/Martin_Abadi/Papers/pwd-rev
ised/pwd-revised.html!
> --Matthew E Fisher
> [EMAIL PROTECTED]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 15:45:49 GMT
In article <7ugd7q$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
> DJohn37050 <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> At a recent ANSI X9F1 meeting, where particpents consisted of
vendors,
> bankers,
>> auditors and government, there was overwhelming consensus that NIST
should
>> incorporate future resiliency considerations into AES criteria.
>
> This is so vague as to be meaningless. Can one winner have the
> requested resiliency?
It is also a mis-statement of what happened. The working group
voted to suggest that NIST should *consider* reading documents that
discuss "future resiliency", and *not* "NIST should incorporate....."
We did NOT vote to recommend to NIST that AES should incorporate
"future resiliency", but only to recommend to NIST that they should
think about it as part of their review process.
>
> No one is saying that an implementation cannot choose one algorithm,
>just allow
>>the ones that want to (for whatever reason) to be allowed to implement
> more than one
But they can do that anyway!
> and do this in the context of the standard.
Then it is no longer "a standard".
>
> Remember that this is the same committee of idiots who think that
> RSA implementations should only be allowed to use a certain
> very restricted class of primes when generating RSA keys.
I fought long and hard against that requirement. To no avail.
>
> Bankers are not the best ones to be making communications
> security decisions.
Agreed. But they are competent to decide upon interoperability
standards for their industry. They understand their needs better than
others.
Also, there are some actual cryptographers on the committee
(me, Rich Ankney, Rob Zucherato, Mike Wiener, Simon Blake-Wilson,
Paul Timmel etc.)
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 19 Oct 1999 17:55:48 +0200
Bruce Schneier wrote:
>
> On 19 Oct 1999 03:37:50 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>
> >It is REQUIRED to put 2 independent BRAKE systems in EVERY CAR. This is for
> >safety.
>
> Yes. But if it were a security system, then the car would fail if
> EITHER brake failed. This would be worse than having only one brake.
No, Bruce!
This is like the difference between resistance and conductivity.
To increase the resistance you put your resistors (crypto algorithms) in
series, not in parallel, which would indeed reduce the strength to the
weakest link.
I'm not saying that it will be very convenient to have to work with
3*128 = 384 bit keys for every transmission, but if you want all three
algorithms, then that's just what you'll have to do.
Splitting a single 128-bit key across the three systems, or even worse,
share it between them, would be criminally stupid.
OTOH, I don't like the suggestions to pick a random algorithm from a
huge set, to paraphrase Knuth: "Cryptography is too important to be left
to chance".
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 16:26:53 GMT
In article <7ufulk$l15$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> There is no upper bound on the entropy of a pass-phrase; standard
> English has somewhere between 1 and 2 bits per character, depending
> on the model. So if you need a 128-bit passphrase, you can simply
> memorize a 128-character sentence.
Plain English is close to 1 bit entropy per character. I have published
a list of 4096 common and short English words (see
www.tecapro.com/makepass.html); if you randomly choose words from that
list you get a little over 2 bits of entropy per character and can
build shorter pass phrases.
The important question is how to make entropy easy to remember.
Certainly pass phrases are easier to memorize then random characters
and digits. I think it is a good idea to produce several random pass
phrases, choose the easiest one, and move words around in it. You loose
some entropy in this process, but the resulting pass phrase is much
easier to memorize. Maybe there are other ways to improve "memorability
per entropy bit". It would be interesting to have a study that compares
different methods of producing memorable entropy. After all, it may
turn out that it is easier to memorize a normal English phrase of 128
characters than a pass phrase of 64 characters.
A related problem is: how do you produce a normal English phrase?
Picking one out of a book won't do because there are not 2^128 phrases
printed. Asking the user to compose an English phrase won't work in
many cases because people will tend to produce common phrases such as
"I was born there and my mother's name is such".
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: detecting backdoor in prime generator
Date: Tue, 19 Oct 1999 11:09:17 -0600
In article <7uhttg$b4l$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Please start by defining what it means for a prime generator to
> have a back door.
>
> Generally speaking, primes themselves don't have backdoors. A
> public key can have a backdoor, but the public key has structure
> over and above that possessed by a prime.
>
> I suspect that any definition you come up with will be context
> dependent, i.e. dependent on the USE of the prime. A backdoor for
> RSA is not the same as a backdoor for DSA. I doubt you can define a
> general backdoor for a prime generator.
>
> So let me ask for a definition.
I suspect what's really being suggested here is a level of
predictability in the "random" numbers that are chosen as candidates
to test for primality. If the group of candidates that will be
generated is small, then the number of possible keys generated is also
small, and it becomes relatively easy to test among this limited set
of possibilities.
In this sort of situation, the primes themselves are basically
irrelevant -- even if you could prove that all of them were "strong"
primes, if the program could really only produce a few million
different possible keys, there'd be no reason to deal with factoring
the key at all; it'd be much simpler and quicker to exhaustively test
against all the keys the program would produce. Of course, generating
keys is slow enough that most people will never attempt to generate
millions of them to find that they start getting the same keys far
sooner than they really should.
Of course, all of the above is purely speculation about what people
really meant. AFAIK, it doesn't apply to PGP, and obviously it's
meaningless except with respect to a particular product, since it
really has nothing to do with the encryption algorithms involved.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
