Cryptography-Digest Digest #426, Volume #10 Mon, 18 Oct 99 06:13:03 EDT
Contents:
I need "Alternating Generator" Info ([EMAIL PROTECTED])
Re: Strengthening passwords against dictionary attacks (Bill Unruh)
Re: Strengthening passwords against dictionary attacks (Thomas Wu)
Making hard Hamiltonian path instances? (Xcott Craver)
Re: Strengthening passwords against dictionary attacks ([EMAIL PROTECTED])
Re: Ciphertext Stealing in CBC Mode ("Trevor Jackson, III")
Re: Newbie Cryptology question : is user 'key unkown' crypting possible?
Re: Strengthening passwords against dictionary attacks (David Wagner)
Re: Strengthening passwords against dictionary attacks (Tom St Denis)
Re: Newbie Question -- Matrix multiplies in Twofish ([EMAIL PROTECTED])
Re: Biometric Keys are Possible (Peter Pearson)
Re: Biometric Keys are Possible (Francois Grieu)
Re: looking for elliptic curve primer (Safuat Hamdy)
Re: newbie: resources needed. (Eric Hambuch)
RE: Disappearing Inc. ("Josep F")
Eric Young's libdes (Jesper Gadeberg Jensen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: I need "Alternating Generator" Info
Date: Sun, 17 Oct 1999 23:35:38 GMT
Where Can I find source code for an Alternating Generator", I have to
do this for a project, and am trying to understand the program.
I want to re-write it in Java, with OOP.
Thanks for your help in advance.
HAL
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Strengthening passwords against dictionary attacks
Date: 18 Oct 1999 00:32:16 GMT
In <7udhan$esn$[EMAIL PROTECTED]> Tom St Denis <[EMAIL PROTECTED]> writes:
>Basically any login system should work like this
>1) Server sends R (random bit string, say 32 bits)
>2) Remote sends a = HASH(R + password) and R'
>3) Server checks a, and sends b = HASH(R' + password)
>4) Remote checks b
Server has to store that password in the clear.
Remote person can still launch a dictionary attack, having both R and a.
Ie, that password had better be a good one ( not the weak thing you
suggested).
Man in the middle attack works.
Eve grabs communication. Passes R on to remote, gets a, passes on a, and
R' gets b, sends on b. Remote
thinks he is connected to server, but is connected to Eve. Server thinks
he is connected to remote but is connected to eve.
Is it better than clear text password? yes, except for storage of cler
text passwords. But one can do better.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: 17 Oct 1999 17:31:46 -0700
Tom St Denis <[EMAIL PROTECTED]> writes:
>
> Basically any login system should work like this
>
> 1) Server sends R (random bit string, say 32 bits)
> 2) Remote sends a = HASH(R + password) and R'
> 3) Server checks a, and sends b = HASH(R' + password)
> 4) Remote checks b
>
> 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 PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: comp.theory
Subject: Making hard Hamiltonian path instances?
Date: 18 Oct 1999 00:49:46 GMT
Hi,
I'm refining a protocol which involves creating a graph with
a hidden (and, I hope, hard-to-find) Hamiltonian path. The
obvious approach of creating a graph consisting of only a
path, then adding edges, then scrambling, leaves me wondering what
a "good" number of edges are, and what pitfalls to avoid in
terms of avoiding "easy" problem instances.
A related question is: how many nodes are typically needed
for computers today to take a sufficiently long time? I.e.,
what is a good-sized problem instance for implementing such a
protocol today? We know how big a modulus is needed for factoring
to take N years (maybe,) but how big a graph is needed for
PATHing to take N years?
So far, my search has yielded theoretical discussion of the
HAMILTONIAN PATH problem, reductions, various zero-knowledge
proofs, some straightforward algorithms meant to illustrate
finding one in small examples. What I need to find is a
ref. to actual implementation issues in using PATHs for
zero-knowledge proofs, or to "fast" search algorithms.
Any pointers to information (or pointers to pointers to
information) would be greatly appreciated.
Thanking you for your time,
Scott
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Strengthening passwords against dictionary attacks
Date: Mon, 18 Oct 1999 00:49:28 GMT
In article <7udhan$esn$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7ucue1$3ej$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > ...
> > Strengthening passwords against dictionary attacks
> > The salt is not secret but should be evenly distributed across the
> > 2^1024 space.
>
> Why so many bits? You could simply use 32 bits and make dictionary
attacks
> infeasible.
>
> Basically any login system should work like this
>
> 1) Server sends R (random bit string, say 32 bits)
> 2) Remote sends a = HASH(R + password) and R'
> 3) Server checks a, and sends b = HASH(R' + password)
Tom,
How does ther server get the password? Is the HASH two way or is
the plaintext of the password stored on the server? How
does the server check 'a' if the hash is a combination of a password
and a random value?
> 4) Remote checks b
Why this step? Does it avoid spoofing or other 'fake' servers?
>
> Simple as that.
>
> Tom
Sorry, I should have made my intention more clear. My idea would
be for systems that are vulnerable to dictionary attack. A Windows or
Unix password file, a virtual hard disk, encrypted files in general,
etc are vulnerable to being copied and then attack on a seperate
computer. Your idea seems applicable to logging in over a network
but not to off site attacks. Is that right?
The large number of bits in the salt is overkill no question. On the
other hand, bits are quite cheap these days and security breaches are
very expensive. A few K per user is nothing.
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 17 Oct 1999 21:04:25 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ciphertext Stealing in CBC Mode
[EMAIL PROTECTED] wrote:
> Eric W Braeden ([EMAIL PROTECTED]) wrote:
> : I'm reviewing the idea of Ciphertext Stealing in CBC mode
> : and having a little trouble with Figure 9.5 page 196 in AC.
> : Because Bruce didn't explain much in the book, the Figure
> : just isn't clear to me. I would seem that the last full block
> : and the final partial block are flipped around. Also what
> : is the symbol phi supposed to be? Any good discriptions
> : of Ciphertext Stealing out there?
>
> Well, "Tying Up Loose Ends" mentions Ciphertext Stealing among other
> things. The encipherment which includes a partial block should just be
> done in plain ECB mode, since part of the previous block is obscured, so
> one can't decipher if CBC continues.
>
> (somewhere on my page, http://www.ecn.ab.ca/~jsavard/jscrypt.htm is the
> index)
>
> The idea is simply this: after enciphering as many full blocks as you can,
> encipher the last partial block, and a part of the last full block (after
> it was already enciphered) of sufficient size to make what you are
> enciphering a whole block.
>
> Ciphertext Stealing involves taking those two pieces, and flipping them
> around, because that way _alignment_ is maintained. This can be important
> if the cipher has some types of weakness, or if your message is an odd
> number of bits long, so that not maintaining alignment makes things more
> complicated.
I believe you can describe this as using the next to last block as filler to
pad out the last block to an even block boundary.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Newbie Cryptology question : is user 'key unkown' crypting possible?
Date: 18 Oct 99 01:20:20 GMT
Chad Hurwitz ([EMAIL PROTECTED]) wrote:
: but this may be the only way to do it.... just wondering if anyone has
: key generation technique that will generate a key and encrypt a message
: with out "easily" revelaing the key to the user of the program generating
: the encryption.
Public-key cryptography techniques let someone know the key to encrypt a
file without knowing the key to decrypt it.
But I think that for what you are doing, what needs to happen is this: the
user creates the file, then as soon as possible afterwards goes on the net
to the central authority, which signs the file with the time it was told
about it. If the connection fails, then it can always sign the file on the
next try. Because there is nothing to stop the user from creating the file
on his computer, with his computer's clock set wrong.
I don't know, of course, if that is good enough for your application.
John Savard
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Strengthening passwords against dictionary attacks
Date: 17 Oct 1999 18:11:57 -0700
In article <7ud46d$m9r$[EMAIL PROTECTED]>,
Solar Designer <[EMAIL PROTECTED]> wrote:
> 1. Throwing away salt bits results in non-constant check times for
> different users. This is both inconvenient (some users might have
> to wait 10 seconds to achieve an average of 5), and dangerous. Timing
> attacks might be possible, such as on sniffed encrypted sessions of
> a user authenticating to such a system. These attacks would reveal
> several bits of those you've thrown away. This is really bad.
Timing attacks can be prevented by having the server check the salt-space
in a random order (chosen anew each time, for each user).
(It's a good point, though; I haven't seen that attack described anywhere
else before.)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: Mon, 18 Oct 1999 01:39:21 GMT
In article <7udqqn$kj8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> How does ther server get the password? Is the HASH two way or is
> the plaintext of the password stored on the server? How
> does the server check 'a' if the hash is a combination of a password
> and a random value?
If the server has the password, it can calc HASH(R + password). It may not
be ideal for the server to store the password though. I think dynamic
challenge responses are better then static ones if you have a good RNG.
Otherwise use one static SALT with the password.
>
> > 4) Remote checks b
> Why this step? Does it avoid spoofing or other 'fake' servers?
The server could simply say 'um, yes that's the password now send sensitive
files to me'. This way you are both authenticated.
> Sorry, I should have made my intention more clear. My idea would
> be for systems that are vulnerable to dictionary attack. A Windows or
> Unix password file, a virtual hard disk, encrypted files in general,
> etc are vulnerable to being copied and then attack on a seperate
> computer. Your idea seems applicable to logging in over a network
> but not to off site attacks. Is that right?
Yea.
> The large number of bits in the salt is overkill no question. On the
> other hand, bits are quite cheap these days and security breaches are
> very expensive. A few K per user is nothing.
But that few K better be random.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Newbie Question -- Matrix multiplies in Twofish
Date: Mon, 18 Oct 1999 04:35:33 GMT
In article <7tbdi5$lpa$[EMAIL PROTECTED]>,
"Les Lawrence" <[EMAIL PROTECTED]> wrote:
> Twofish makes extensive use of matrix multiplies (RS,MDS). I
understand
> matrix multiplies in an algebraic sense but my feeble attempts to
duplicate
> the test results (even the simple task of generating the S-Box keys)
on my
> hand calculator fails. Would someone please describe the nit gritty of
how a
> matrix multiply is performed in crypto math, i.e. the element by
element
> multiplication and summation?
> Thanks.
>
>
pls. check a reply to a similar question by paul crowley on
www.hedonism.demon.co.uk/paul/postings/news-546.txt
this explains the basics of what u need to do here.
-regards,
rasane_s.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Biometric Keys are Possible
Date: Sun, 17 Oct 1999 21:52:50 -0700
[EMAIL PROTECTED] wrote:
>
[snip]
> Ah, but along with a user's ID, a system can store the check bits of an
> error-correcting code that can correct a limited number of single-bit
> errors in the user's biometric data.
>
> Doubtless someone has thought of this before, and this idea is the subject
> of a patent somewhere, but I thought it worth mentioning that this kind of
> technique exists as an option.
In fact, a few years ago I implemented a demonstration system
along these lines, along with Scott Strait and Sailes Sengupta
at the Lawrence Livermore National Lab. From the 72-bit readings
of a Recognition Systems hand-geometry reader, plus error-correction
information, we could consistently retrieve a 16-bit (wow!) key,
which we then used in some Diffie-Hellman-like scheme. Obviously,
16 bits is not cryptographically significant; this was only a
proof of principle. Since then, I have looked longingly at
descriptions of IriScan iris readers, which produce data
well suited to this technique, from which I believe keys in
the neighborhood of 60 to 100 bits could be reliably extracted.
Of course, there are some bothersome questions like, how much
you want to rely on the secrecy of a biometric that you show
to everybody you meet . . .
- Peter
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Biometric Keys are Possible
Date: Mon, 18 Oct 1999 09:11:51 +0200
[EMAIL PROTECTED] wrote:
> Some quantities, like the number of fingerprint ridges between two
> features, are discrete. Extracting them from a scan of a fingerprint is
> still a complicated process, requiring advanced software.
and in a later message:
> a few years ago I implemented a demonstration system
> along these lines, along with Scott Strait and Sailes Sengupta
> at the Lawrence Livermore National Lab. From the 72-bit readings
> of a Recognition Systems hand-geometry reader, plus error-correction
> information, we could consistently retrieve a 16-bit (wow!) key.
I doubt any biometric technique is able to produce a discrete
number that is the same from device to device, with high probability
and most individuals. That is, I believe two unconnect biometric
devices will sometime produce different numbers for the
same individual.
I'm not at all saying biometry don't work. It is indeed possible to
summarize measured characteristics into a moderate amount of data,
and still be able to perform meaningfull comparisons. It may
even be possibile to quickly and reliably match an individual from
a huge database of summaries given only measured characteristics.
But a database is needed, of size growing about linearly with the
number of individuals reliably recognized.
Producing a discrete and repeatable discrete identifier from
measured characteristics, I can't believe it no matter the amount
of advanced software involved.
If we take the fingerprint ridges example, it is bound that for some
individual one ridge will be so faint that it is sometime counted,
sometime not, and this will produce a different number.
The probability of this occuring increase quickly (exponentialy ?)
with the size of the identifier. It seems unbelievable that any
kind of forward error correction is built into a physical
characteristic of individuals, so I don't think there is a way out
of this.
This non-uniqueness is a practical issue in many applications,
because it makes the output of a biometric device not directly
usable as a conventional search, identification, or crypto key.
For example, a Smart Card can easily make a binary comparison of
a submitted PIN to an internaly stored PIN, and unlock some function
if it matches. Comparing biometric characteristics requires
a much more complex process.
I'd appreciate pointers to papers on the topic, BTW.
Francois Grieu
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: looking for elliptic curve primer
Date: 18 Oct 1999 09:21:29 +0200
Max Kubierschky <[EMAIL PROTECTED]> writes:
> I need an introduction to or book on elliptic curve
> cryptosystems (and elliptic curves in general).
> I've a medium level background in algebra.
There're several choices:
Blake, Seroussi, Smart
Elliptic Curves in Cryptography
Cambridge University Press (1999)
Koblitz
Algebraic Aspects of Cryptography
Springer Verlag (1998)
Menezes
Elliptic Curve Public Key Cryptosystems
Kluwer Academic Publishers (1993)
Rosing
Implementing Elliptic Curve Cryptography
Manning Publications (1998)
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: newbie: resources needed.
Date: Mon, 18 Oct 1999 10:01:09 +0200
Aslak Johansen wrote:
>
> Salut, Mundi
>
> I am a student at a Danish Gymnasium (which I believe equals a
> 'College of higher education' or a 'Sixth form College'). As a last-year
> project (this year) I am going to write about Cryptology, Knapsack, RSA
> ...
> I am now yet sure about the title, but the point is, that I need some
> resources (This couldt be books, links, algorithms, White Papers etc.).
> Therefore I come to You and ask for help ...
Try:
http://cacr.math.uwaterloo.ca/hac where you can find the "Handbook of
Applied Cryptography" online!
Eric
------------------------------
From: "Josep F" <[EMAIL PROTECTED]>
Subject: RE: Disappearing Inc.
Date: Sun, 17 Oct 1999 17:19:19 +0200
> They apparently assume they can prevent anyone from making a backup
> copy of an email previously read. They ignore, or pretend to ignore,
> the existence of utilities to capture the screen, or better the text
> beeing rendered on the screen. I think they should limit their claim
> to: "so that nobody can ever read it again without access to data
> obtained from a previous reading".
>From his FAQ:
"10. Can't someone defeat the system by printing or doing a screen capture?
It is important to understand the goals of Disappearing Inc.'s technology.
Disappearing Inc.'s service addresses the common scenario where all parties
want to communicate privately and without fear that their messages will be
exposed some time in the future. If one or more of these parties is not
interested in a private exchange then no system can protect that
communication. We call this the "saboteur problem," and we think that
addressing this harder problem places an unreasonable burden on common email
communications. "
So the system is based on fair practices by all parties. If somenone makes a
screen capture of the plaintext, then the system is useless, they trust the
parties will not do such thing.
I don't see the advantages of this system over a common PGP symetric
cryptography where the parties keep their keys and agree on a date to
destroy their copies.
If a malicious party uses Disappearing system, they will make a screen
capture before the expiry date and will be able to produce infinite copies
later. If a malicious party uses PGP, then he will not destroy the key on
the agreed date and will be able to produce infinite copies later, no
difference at all. Moreover, Disappearing has a disadvantage, you have to
trust them since, after all, they have the keys and can read your messages.
I'm far from an expert, but I really can't see the advantages.
------------------------------
From: Jesper Gadeberg Jensen <[EMAIL PROTECTED]>
Subject: Eric Young's libdes
Date: Mon, 18 Oct 1999 08:16:26 GMT
Can anyone tell me how to compile Eric Young's libdes for DOS. I have
come to the conclusion that I might be missing some critical part of
Borland C++ (or maby my version is just to old)!
When I run the following: "make -f makefile.bc" I get (besides a lot of
other warnings):
...
Borland C++ 4.52 Copyright (c) 1987, 1994 Borland International
ofb64ede.c:
Warning des_locl.h 184: Redefinition of 'random' is not identical
bcc -c -ml -d -3 -O2 -DMSDOS supp.c
Borland C++ 4.52 Copyright (c) 1987, 1994 Borland International
supp.c:
Warning des_locl.h 184: Redefinition of 'random' is not identical
del libdes.lib
File not found
makersp "+%s &\n" MAKE0000.@@@ >libdes.rsp
Bad command or file name
tlib /0 /C libdes.lib @libdes.rsp,nul
TLIB 4.00 Copyright (c) 1987, 1994 Borland International
DOS-reported error: No such file or directory
opening 'libdes.rsp'
** error 1 ** deleting libdes.lib
C:\BC45\BIN\DES>
Can you help? If anyone has libdes compiled for DOS, I would
really appreciate it if you could send me a copy by E-mail!
-Jesper
------------------------------
** 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
******************************
