Cryptography-Digest Digest #831, Volume #12 Tue, 3 Oct 00 20:13:01 EDT
Contents:
Re: Proper way to intro a new algorithm to sci.crypt? (Albert Yang)
Re: Rijndael test vectors ("Brian Gladman")
Re: Q: does this sound secure? (Anton Stiglic)
Re: Authenticating a PIN Without Compromising the PIN (John Myre)
Re: RC6 royalty free or not? (Mok-Kong Shen)
Re: Q: does this sound secure? (John Myre)
Re: Democrats, Republicans, AES... (Mok-Kong Shen)
Re: RC6 royalty free or not? (Tom St Denis)
Re: Q: does this sound secure? (John Myre)
Re: Authenticating a PIN Without Compromising the PIN (David Schwartz)
Re: Requirements of AES (Tom St Denis)
Re: Authenticating a PIN Without Compromising the PIN ("David C. Barber")
Re: Rijndael test vectors (Roger Schlafly)
Re: Requirements of AES ([EMAIL PROTECTED])
Re: Advanced Encryption Standard - winner is Rijndael (wtshaw)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? ("Joseph Ashwood")
Re: Requirements of AES ("Joseph Ashwood")
Re: Requirements of AES (Jim Gillogly)
----------------------------------------------------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Proper way to intro a new algorithm to sci.crypt?
Date: Tue, 03 Oct 2000 22:09:08 GMT
While I am not a big fan of Mr. BS as you so address him (I have to
admit, that makes me laugh), I give him quite a bit of respect,
certainly more than you give him.
As for Mr. Wagner, Mr. BS's sycophant as you generally refer to him as,
I have no beef against him...
My algorithm is not too bad. Newbie mistakes? Probably not too many of
them in there, as I've done (or tried to have done) my homework on this
one. There are a lot of weak points, but I point them out as all good
cryptographers do, and I attack the algorithm pretty hard. I've had
quitea a few people look at it, and although not as strong as I would
have liked it to be, it certainly is not a "Mr. BS can break it in a few
seconds using Wonder Woman's lasso and Mr. Wagner's Slide attack" type
of thing...
I hope to get all my ducks in a row, and put up a decent website
introducing the algorithm, at that point in time, I can only wait with
anticipation as slide attacks and amplified boomerang attacks come 'a
knocking on my door...
Albert
> I am glad it cures cancer. But to be honest if your method
> is any good it is unlikely to recieve high praise here. If it is
> easy to break and one that common newbies do. Then you may get a
> response from Mr BS saying something to the effect that it's junk
> and more proof to his claim that newbies can't design crypto.
> If it is good you could get a comment from his side kick Wagner
> who may says its "dead meat" and his slide attact proves it. But
> of course Wagner will never test it. And if some kind person does
> and then shows to people here the slide attack does not work on it.
> Wagner will brush it off and say he really never followed what the
> code did in the first place. But then of course of you don't
> follow what actaully happens here you will never know.
> But if your really lucky you may get into an excahnge with Ritter
> or Mr Onions who would take the time to look at it and they would
> give you honest anwsers that may be of some help.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott LATEST UPDATED source for scott*u.zip
> http://radiusnet.net/crypto/ then look for
> sub directory scott after pressing CRYPTO
> Scott famous Compression Page
> http://members.xoom.com/ecil/compress.htm
> **NOTE EMAIL address is for SPAMERS***
> I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Tue, 3 Oct 2000 23:11:41 +0100
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian Gladman wrote:
> > No - the cipher blocks are passed through the algorithm 10000 times in
each
> > of these tests, not just once.
> > However, the ECB_VK and ECB_VT test vectors use the algorithm just once.
>
> Ahh, thanks! ECB_VT uses the key of all zeros. It looks like I can
> reproduce those values, except that the bytes are scrambled.
> Presumably just some byte order problem that I can figure out.
Welcome to the endian world of AES!
A world I hope we can remove by getting the specification right on such
matters.
Brian Gladman
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: Tue, 03 Oct 2000 18:12:06 -0400
This doesn't sound secure depending on your treat model:
"William A. McKee" wrote:
>
> I have to ask the user for an user id and password in a Java applet (client)
> then validate it on a server. Does this sound like a secure scheme?
>
> 1) the server issues a random session key (32 bits).
> 2) the user id and password are hashed (MD5) by the client.
> 3) the session key and hash key from 2 are hashed (MD5).
By hash key I guess you mean the output of the hash value
obtained in 2.
Looks like you are hashing to many times, you don't have
to hash the session key.
What you call a session key seems to serve as a nonce,
should call it nonce it that is the case.
> 4) the user id and hash key from 3 are sent to the server.
> 5) the server looks up the user id in a password file then hashs the session
> key and the stored hash key (previously computed, the same as in 2).
So the hash key H(password) is stored on the server side.
The security of your scheme depends on the fact that people
don't have access to the contents in the server;
Anybody who knows H(password) can authenticate to the
server (assuming everyone can figure out what the id
corresponding to the password is, you should assume this)
You might want to have the server encrypte these stored
values (the H(password)) in an ecrypted format, and you don't
ever want the client to send H(password), directly, on the
clear.
Coming down to what you need, you could just forget about
hashing the password, and have the following
Server picks random nonce and sends it to Client.
Client computes Hash(nonce, password),
Client sends H(nonce, password), id to Server.
Server looks up id in database,
decrypts the entry to get password, computes
H(nonce, password) and verifies if it's what
Client sent him).
This is a sort of a proof of a shared secret scheme.
Anton
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Tue, 03 Oct 2000 16:04:47 -0600
David Schwartz wrote:
<snip>
> There is nothing useful anyone can do with the unit ID and the
> encrypted PIN. That's all that's sent over the wire.
Replay. You don't learn the PIN but you don't need it.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RC6 royalty free or not?
Date: Wed, 04 Oct 2000 00:31:41 +0200
"Sami J. M�kinen" wrote:
>
> I couldn't tell by reading the papers from RSA webpage that
> is RC6 royalty free or not (to use in shareware program)?
To get a sure answer, why don't you write to the company?
M. K. Shen
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: Tue, 03 Oct 2000 16:15:29 -0600
"William A. McKee" wrote:
>
> I have to ask the user for an user id and password in a Java applet (client)
> then validate it on a server. Does this sound like a secure scheme?
No. An eavesdropper ("Eve") can learn enough to do an
off-line dictionary search for a password. See below.
>
> 1) the server issues a random session key (32 bits).
Eve intercepts (copies) this message.
> 2) the user id and password are hashed (MD5) by the client.
> 3) the session key and hash key from 2 are hashed (MD5).
> 4) the user id and hash key from 3 are sent to the server.
Eve intercepts (copies) this message.
> 5) the server looks up the user id in a password file then hashs the session
> key and the stored hash key (previously computed, the same as in 2).
> 6) the two hash keys (from 3 and 5) are compared.
> 7) the server issues a "PASS" if 6 compares true (and moves into a "logged
> on state") else it issues a "FAIL"
>
> Passwords are at least 6 characters long with at least one non-alpha
> character.
Eve does a dictionary search, looking for a password which
matches the data she intercepted. She succeeds and now knows
your password.
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Wed, 04 Oct 2000 00:43:06 +0200
Albert Yang wrote:
>
> <snip>
> > So it is likely for one of the candidates to increase the
> > round number by a factor of 100, thus gains the 'highest
> > level of security margin' and win. Does that correspond to
> > what you mean?
> >
> > [snip]
>
> No, this is not what I mean. I mean leaning on the side of
> conservatism, that means no new math, concepts that are well understood,
> SP network has been around for a LONG time, it's well understood, same
> with Feistels. Using primatives that we know a lot about, using sound
> logic, nothing new and flashy, I mean if I wanted "new and improved",
> wouldn't I have rooted for the Decorollated one? Nope. I think Serpent
> was way overly conservative, used things we know a lot about, had great
> pedigree, and probably gave me the most confidence and the warmest
> fuzzies..
>
> The other one would be RC6, which had a lot of attacks against it
> because it has a lot of cryptoanalysis under it's belt, via the RC5
> inheritance. It's elegant, simple, easy to remember, easy to program
> from memory, easy to check for proper coding, and no S-boxes to
> memorize. While the "margin of security" was not as good as Serpent, I
> have to say that something I can put on the back of a napkin has got to
> be impressive regardless what people say...
I don't understand your definition of 'margin of security'.
If cipher A has n rounds and can be broken with m rounds,
while cipher B has n1 rounds and can be broken with m1
rounds and n-m > n1-m1, do you think that A has a higher
margin of security? If you don't mean that kind of stuff,
how are you going to compare the 'margin of security'
without being very fuzzy?
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC6 royalty free or not?
Date: Tue, 03 Oct 2000 22:29:06 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Sami J. M�kinen) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I couldn't tell by reading the papers from RSA webpage that
> is RC6 royalty free or not (to use in shareware program)?
>
> I'm talking about the algorithm itself, not any implementation.
To the best of my Knowledge (TTBOMK?) you must now license RC6, but I
wouldn't use it anyways... unless you add say 8 rounds to it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: Tue, 03 Oct 2000 16:32:47 -0600
Anton Stiglic wrote:
<snip>
> This is a sort of a proof of a shared secret scheme.
>
> Anton
Except the secret is too small: a 6 character password.
JM
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Tue, 03 Oct 2000 15:49:51 -0700
John Myre wrote:
>
> David Schwartz wrote:
> <snip>
> > There is nothing useful anyone can do with the unit ID and the
> > encrypted PIN. That's all that's sent over the wire.
>
> Replay. You don't learn the PIN but you don't need it.
>
> JM
Just include a sequence number in the encrypted data.
DS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Tue, 03 Oct 2000 22:52:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : 1, Security
> : 2, Versatility
> : 3, Security
>
> : I fail to see how Serpent or Twofish failed to beat Rijndael with
those
> : restrictions. [...]
>
> From the conclusion of the AES report, this is how:
Perhaps I should rewrite the question in a form you can understand.
Why wasn't Serpent or Twofish picked?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Tue, 3 Oct 2000 15:59:34 -0700
You invalidate that user account after a given few number of bad guesses.
The user needs a new account which the attacker must then determine before
he can continue his brute force attack. Same as an ATM machine that eats
the card after three wrong attempts.
*David Barber*
"Guy Lancaster" <[EMAIL PROTECTED]> wrote in message
news:8rd6d8$4a9$[EMAIL PROTECTED]...
> The problem is that PINs must be short (i.e. a few digits)
> which makes it all too easy for a computer to exhaustively
> search for the correct value given sufficient information to
> know when it has the correct value.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Tue, 03 Oct 2000 16:02:28 -0700
Brian Gladman wrote:
> Welcome to the endian world of AES!
> A world I hope we can remove by getting the specification right on such
> matters.
Yes. I once implemented DES based on the spec, and then discovered
that others used the bits in a different order. It seems the
official spec talked about bits, but not bytes, leaving the
order of bits in a byte ambiguous.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Requirements of AES
Date: Tue, 03 Oct 2000 23:38:23 GMT
> Does it matter how fast the cipher is if it's not secure? Now right
> now Rijndael is secure, but it has had the most number of rounds
broken
> compared to the other ciphers. While that's not a definate saying it
> is an indication of the ability for people to attack it.
The best serious breech of Rijndael is 6 rounds, with expensive attacks
on 7 rounds. There is no known attacks on 128 bit keys on Rijndael
after 7 rounds. Thus the security margin is 10/7 on 128 bit Rijndael.
There also exist attacks on 8 and 9 round 192/256 bit Rijndael, the 9
round attack using 256 related keys. The 9 round attack has no pratical
application. Both the 8 and 9 round attacks require more than a
practical amount of work, or data. The amount of chosen plaintext being
more information than atoms that exist in the universe. Even so the
margin of 256 bit Rijndael is 14/9.
These margins are clearly not as good as Serpent. But is 10/7 and 14/9
insecure, even going forward 10 years? 20 years? 30 years? Practically
the margins are more like 10/6 and 14/7.
Twofish has a related key attack on 11 rounds. The best practical
attack is on 6 rounds. 16/6 is a good margin, but 16/11 is more like a
Rijndael margin, actually worse.
And consider DES. Full round DES is broken, but practically it's
strength requires 2^55 work. For all the study done on DES, no one is
alarmingly extending the breaches.
Remember DES is the primate behind 3DES which is used used just about
everywhere.
> I hope people just disregard AES and pick the ciphers they know are
> better.
I personally would have liked to see 16 round Rijndael, or at least
12/14/16 round Rijndael. Prehaps NIST could make the number of rounds a
parameter as part of the AES. It's a pity Serpent didn't win; but it
didn't; but even with the lower margins, Rijndael still makes a good
AES.
Unseenrising
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 17:03:57 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> ....no Foreign
> Office would be using the crap algorithms their cocky programmers
> told them were secure -- they'd be using something they <knew> was
> good enough. If it was true and not believed, then people in
> industry would shy away from AES because they thought it could
> be broken -- after all, the Gov't wouldn't say it couldn't break
> it unless it actually could, shutting off that source of intel.
> If it was false and the academics eventually duplicate the crack,
> the gov't gets a black eye, either from being found to be lying
> or being found to be incompetent, depending on the perception of
> whether they were being straightforward.
>
Pangrams in the spirit of The Game (Match the Algorithm):
46) *View Rijndael qualms as zonked box in encryption fight.
51) *View Magenta, a shade of red, zilch, just bunker quaggy logic pox.
52) *I liked zany, jinxed thoughts Frog piqued with comical bravado.
50) *Mars' orbit is hexed, not preamble to lazy advantage of quick jaw.
54) *Lax Hasty pudding stuck somewhere, vanquished for bad spice jazz.
57) *Take defender Loki outback to Pieprzyk having major quixotic glows.
58) *Nix quized E2, et tu brute, in spite of viewing jade gal, thank you
very much.
59) *Beam Safer, but wax that knowing pulverizes coquettish butterfly judo.
59) *RC6 out of class? Profess how becoming vexed in hejira is a quizzical yoke.
61) *Two fishes serve as bait for game. Just pluck dazzled from box
beneath quay.
63) *Superman's x-ray vision fails in krypton haze. Judge that queasy
words becalm.
64) *Big Deal, not bridging to outer riches, know jump favors quick not
lazy for xmas.
64) *Big snakes coil, jump forward, kill, and devour their quarry, except
for zombies.
68) *Cast not your hopes to Entrust betwixt knowing daqueri and jacuzzi,
film at eleven.
68) *Provable security is vowed an elusive major goal in quest of exact
knowing in haze.
--
A Pangram: 52) *Part of job is making whimsical, zippy, and vexing key sequences.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 3 Oct 2000 16:07:51 -0700
It all depends on what your speed requirements are. For PGP the most likely
situation is an individual sending and receiving e-mail. For that it has
taken me more than 1/60th of a second to type this so far, so it remains
reasonable to use 4096 bit RSA. Of course for a system like Ebay using SSL,
the situation is substantially different, they require a fairly large number
of negotiations/second, so it would be reasonable to temper the key size
with the speed/cost requirements. So while it is certainly possible to for
them to have a large farm of system dedicated to decryption/verification it
is more reasonable for them to accept the risk of a 1024-bit key being
broken and use such, the same risk requirement would indicate that they
should not go with 512-bit rsa, because it is known to be publically
breakable, and so the extra speed is not worth the extra risk. For me
personally though, with PGP I use 4096-bit because the crypto is not the
bottleneck, I am, so accepting the extra risk of a smaller key is
unjustified (a few minutes + 1 millisecond is not much different than a few
minutes + 1/60 second).
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Tue, 3 Oct 2000 16:23:41 -0700
> Why wasn't Serpent or Twofish picked?
For the same type of reasons that you choose to use 1024-bit RSA instead of
4096-bit or above. As of right now there is no concievable reason to believe
that Rijndael will be broken, so why compromise unnecessarily on the other
qualifications asked for? You or I may not personally agree with the
decision, but from the limited view that they made clear from the beginning
the choice seems to have been proper.
Joe
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Wed, 04 Oct 2000 00:00:14 +0000
Tom St Denis wrote:
> Perhaps I should rewrite the question in a form you can understand.
Your snide attitude isn't helping. You really aren't all that
far ahead of the rest of us in the class.
> Why wasn't Serpent or Twofish picked?
I think you need to get the NIST report. It's really quite thorough.
Here are some of the points from section 6, Summary Assessments of the
Finalists. They noted that although IP was reviewed, they felt that
no algorithm had an advantage over the others in this regard, so this
didn't enter into the evaluation as a distinguishing characteristic.
First, they observed that there are no known security attacks on any
of the finalists, and all five appear to have adequate security for
the AES. They mention criticism of Rijndael for its mathematical
structure and Twofish for its key separation property, but say that
neither of these observations leads to an attack. This, in their
view, indicates that the algorithms are all secure enough, though
they say that MARS, Serpent and Twofish appear to have higher
security margins.
Second, RC6 and Rijndael are on top for en/decryption speed in s/w.
MARS is average, Twofish is mixed across platforms but generally
average, and Serpent is slowest. Rijndael has the fastest key
setup, MARS, RC6 and Serpent are average, and Twofish is slowest.
Third, in restricted RAM/ROM apps Rijndael is the clear favorite,
Serpent is good, Twofish is "suitable", RC6 has a high RAM reqt
for decryption, and MARS is not well suited.
Fourth, Serpent and Rijndael have the best hardware throughput,
RC6 and Twofish have average throughput, and MARS is below average.
Fifth, Rijndael and Serpent use operations that are easier to
defend against power and timing attacks. Twofish's addition op
is harder to defend against those attacks, and RC6 and MARS are
difficult to defend because of mults, variable rots, and addition.
Sixth, Twofish, MARS and RC6 need little extra area in hardware to
accomplish both encryption and decryption. Rijndael has different
encryption and decryption, but can share some area. Serpent uses
different functions, and thus requires the most additional overhead
for both functions.
Seventh, in key agility Twofish is tops, followed by Serpent,
Rijndael, MARS and RC6.
Eighth, they considered additional flexibility, including key sizes
and block sizes not specified in the AES requirements. Each of them
had different advantages here.
Ninth, Rijndael has the most potential to benefit from instruction
level parallelism, and was the only one identified by name on this
criterion.
If you look back across these, each alg is near the top of some
criteria and near the bottom of others, and NIST points out that
any one of these algorithms could serve admirably as the AES, and
that none of them is outstandingly superior to the rest.
NIST explicitly decided not to assign subjective numerical weights
to these, and felt that on balance Rijndael had the edge, but that
it was by no means a no-brainer.
The NIST paper doesn't count heads here: who has the most places
at the top of each list and who ends up most often on the bottom.
They don't ignore the perception that Rijndael and RC6 have less
overkill (my word, not NIST's) in their security than the other
algorithms, but they also don't let it dominate the evaluation.
Your mileage clearly varies on this, but you should acknowledge
that it's not as obvious a blunder as you've been shouting.
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 23:12
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
** 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
******************************
