Cryptography-Digest Digest #394, Volume #10 Mon, 11 Oct 99 15:13:03 EDT
Contents:
Re: Block encryption with variable keys (Bruce Schneier)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Sundial
Services)
Re: Ritter's paper
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Bruce
Schneier)
user authentication (Bill Lynch)
Re: Does anyone have more information? (Francois Grieu)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: Findkey (MLuttgens)
Re: user authentication (Medical Electronics Lab)
Anyone got cryptography design in VHDL for DES, RSA, ... ("P.C. Teo")
Re: user authentication (Peter Gunn)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Block encryption with variable keys
Date: Mon, 11 Oct 1999 17:11:20 GMT
On Wed, 06 Oct 1999 23:51:10 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>I have on many occasions in the past advocated what I term the
>principle of variability in cryptology and have employed it in
>the design of a couple of humble encryption algorithms of my own.
>As also mentioned in a recent discussion thread on Terry Ritter's
>paper, multiple encryption with changing ciphers and parametrized
>ciphers can all be subsumed by this very general principle.
>
>With that viewpoint I like to put up a couple of (maybe unintelligent)
>questions:
>
>Why does DES (and similar block ciphers) keep the key constant
>and not varying from block to block? Would sophisticated attacks
>like differential analysis still function when the key is
>non-constant?
NIST wanted a block cipher, and this is one of the characteristics of
a block cipher. The kind of thing you describe is more like a stream
cipher (you can think of RC4 as a 8-bit block cipher with a key that
changes with ever block; you can think of WAKE similarly).
I can't really tell you why NIST wanted a block cipher over a stream
cipher. I believe it was because DES is a block cipher, and they
didn't want the new standard to be too different. I argued that we
would be better served with a stream cipher.
I also believe that it is possible to get better performance with a
stream cipher than with a block cipher.
>I can see at least two straightforward means of modifying the
>key. One is modification similar in principle to CBC and other
>chainings. The other is letting a PRNG supply the key for each
>block (the PRNG thus drives the block encryption). Certainly
>there is much scope of variations or introducing additiional
>complexities.
There are many ways to modify the internal state of a block cipher to
vary the key with every block. We looked at some of these for
Twofish, although we have nothing developed enough to release. We
should probably get back to work on a steam-cipher variant for
Twofish, if for no other reason than to use the name "Fresh Water
Twofish."
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
Date: Mon, 11 Oct 1999 10:26:25 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Mok-Kong Shen wrote:
>
> I want to highlight a tiny point which is certainly implicitly also
> contained in your paper: Even for a fixed set of n algorithms
> there are n! ways of combination to build a compound cipher. This
> combinatorial explosion alone is an effective defense against
> analysis.
>
The essential point that Bruce mentions is that, if you build an
immensely strong bank-vault door to your home, but beside it is an open
window ... then your home is -worse- than insecure. It's wide open but
you THINK it's safe -- you ASSUME it's safe.
When I look at the crypto algorithms that come out today, it seems to me
that for all practical civilian purposes all of them are quite strong
enough, and have been for some time. True, someone -might- come against
them with all the arsenal that Wile E. Coyote sometimes arrayed against
the Roadrunner (a few good Dr. Seuss comics also come to mind) ... but
everyone else is going to look for some way to go -around- that
impregnable doorway, not through it.
The key, or the key-scheduling algorithm, is an obvious choice. While
algorithms cannot be broken using brute-force, perhaps the key can...
there is usually a "phrase you can easily remember" and so on. The list
of ingenious methods people can use is just as big as the list of
ingenious methods other people use to try to protect things.
Strategies like choosing from among 'n' different cipher algorithms,
mixing them up in various ways or applying several of them in various
ways ... will layer more sheets of bulletproof iron on top of the door
we already have. It will not eliminate that open window if it exists.
I've found that, the more clever you think you are in creating the
protection scheme you put in place -- the more easily you can overlook
"another, obvious-now-that-I-see-it" possibility for going completely
around it.
For instance, at one university I tried to sysop for, I couldn't sleep
one night so I tried to log in... and couldn't! Five minutes later my
password worked -- and lo, "root" was logged on elsewhere. It turns out
that students, who also couldn't sleep, discovered that the password
file was unprotected. They simply replaced it, logged on, quickly moved
it back. The fact that I discovered the hole was quite by accident.
Not a good analogy, I realize, but the point is that the possibility of
this "move the iron door out of the way, go inside, put the iron door
back" attack had simply never occurred to me. Much less that people
were doing it. I changed root-passwords all the time and deceived
-myself- into thinking the system was secure.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ritter's paper
Date: 11 Oct 99 15:51:46 GMT
Tim Tyler ([EMAIL PROTECTED]) wrote:
: If there were many, *many* cyphers where we could prove they had a
: security greater than <X>, then this would be a *big* step forwards...
But that's precisely what we cannot do, except for _extremely_ low values
of <X>. Because the requirement for doing this is to know that, no matter
how much new we may learn about mathematics in the future, we will not
find a better way of cracking that particular cipher.
Essentially, we would have to have finished learning all about mathematics
first, and Godel and others have proved that mathematics is limitlessly
open-ended.
John Savard
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 11 Oct 1999 16:25:33 GMT
On 11 Oct 1999 15:18:28 GMT, [EMAIL PROTECTED] (DJohn37050) wrote:
>Yes, performance is the factor that often constrains solutions. Who cares if
>it is secure but takes too long to meet expectations of the customer.
Agreed. I have had clients that have given me impossible design
constraints for the cryptography. It can be very difficult.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Bill Lynch <[EMAIL PROTECTED]>
Subject: user authentication
Date: Mon, 11 Oct 1999 11:25:44 -0500
Hello,
I'm wondering if this simple type of user authentication scheme would be
secure:
The client requests to logon.
The server acknowledges this and responds back with a random number.
the client hashes their username, password and the random number
together and sends the hash and username back to the server.
the server looks up the client's password based on the username and then
hashes the username, password and random number. if that hash matches
the one from the client, the client is allowed a logon.
The server's random number is good only once.
I've thought of replay attacks, man-in-the-middle attacks and those
don't seem to work.
Care to comment?
Thanks in advance,
--Bill Lynch
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Does anyone have more information?
Date: Mon, 11 Oct 1999 19:58:17 +0200
Update: I received email from Brian Oakley, stating:
"I suppose I was called this (Life President) because I was called
the first Chairman of EIQC. I am no longer active - well, in this field !
I too was rather upset when I learnt of the confusion of Twinkle with
Quantum Computing. (..) I was not aware that there was anything on this
on the EIQC web-site, a site I never visit".
My updated opinion:
The sunday-times article is a mess. As far as I understand it's
a mixup of three things:
- There are ongoing efforts to build quantum computer that could
do anything usefull. For now, a major research goal is to find
ways a quantum computer corrects a significant fraction of it's
own errors.
- Reputable professor Shamir from The Weizmann Institute of Science
(he is the S in RSA) has announced at Eurocrypt '99 the theoretical
design of an optical device called Twinkle that could, if it was
built, help break a 512 bit RSA system in less time than was
possible before [but still nowhere near 1 second or 12 microseconds
at cited, first because Twinkle is not fast enough, second because
there is more to a solution than what the Twinkle device performs].
It should be noted that the Twinkle device is no more a quantum
computer than a candle is a fusion reactor. Also, one 512 bit
RSA key has been broken this year by normal computers.
- The "European Institute of Quantum Computing" has a web site at
<http://www.eiqc.org> with links to an unauthorized copy of the
Twinkle article and announcing the recent creation of an
"EIQC Network". It appears the person listed as "EIQC Life President"
does not endorse the confusion between Twinkle and quantum computing.
references (the first is a two-liner)
<http://www.sunday-times.co.uk/news/pages/tim/99/09/29/timintint02001.html?1341861>
<http://www.EIQC.org/news.html>
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 11 Oct 1999 16:50:03 GMT
Brian says it so well.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (MLuttgens)
Subject: Re: Findkey
Date: 11 Oct 1999 16:51:16 GMT
Thank you.
I know that the PRNG is rather primitive, so I used the successive characters
of the original message as seeds for the RANDOMIZE function.
With that new info, it should be possible to retrieve the used key.
Marcel
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: user authentication
Date: Mon, 11 Oct 1999 11:53:18 -0500
Bill Lynch wrote:
>
> Hello,
>
> I'm wondering if this simple type of user authentication scheme would be
> secure:
>
> The client requests to logon.
> The server acknowledges this and responds back with a random number.
> the client hashes their username, password and the random number
> together and sends the hash and username back to the server.
> the server looks up the client's password based on the username and then
> hashes the username, password and random number. if that hash matches
> the one from the client, the client is allowed a logon.
>
> The server's random number is good only once.
>
> I've thought of replay attacks, man-in-the-middle attacks and those
> don't seem to work.
>
> Care to comment?
It's basic and simple, so that's good. It's
subject to dictionary attacks, the random
number is in the clear, so the attacker just
guesses passwords until the same hash is
found. Then they know the password. That
can be done off line, so the security is
still based on the password.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "P.C. Teo" <[EMAIL PROTECTED]>
Subject: Anyone got cryptography design in VHDL for DES, RSA, ...
Date: 12 Oct 1999 01:10:43 +0800
Please tell me further information of the title above
Thanks
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: user authentication
Date: Mon, 11 Oct 1999 19:37:10 +0100
Thomas Wu wrote:
> Bill Lynch <[EMAIL PROTECTED]> writes:
> >
> > I'm wondering if this simple type of user authentication scheme would be
> > secure:
> >
> > The client requests to logon.
> > The server acknowledges this and responds back with a random number.
> > the client hashes their username, password and the random number
> > together and sends the hash and username back to the server.
> > the server looks up the client's password based on the username and then
> > hashes the username, password and random number. if that hash matches
> > the one from the client, the client is allowed a logon.
>
> This protocol is susceptible to brute-force dictionary attacks against
> the password and provides no secure key-exchange. A man-in-the-middle,
> besides being able to attack the protocol and getting a valid response
> for any challenge, could simply hijack a valid session and use it.
>
> The "state-of-the-art" has advanced to the point where simple
> password-based protocols now resist these attacks. Look at
> SRP, EKE, SPEKE, and technologies like them - they deliver what
> you're looking for.
>
> http://srp.stanford.edu/srp/
> http://www.integritysciences.com/
>
Or, if you're interested in straying a little off the beaten path you could have a
go at breaking SNAKE...
http://www.smdp.freeserve.co.uk/snake.html
ttfn
PG.
------------------------------
** 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
******************************
