Cryptography-Digest Digest #832, Volume #12 Tue, 3 Oct 00 22:13:00 EDT
Contents:
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Authenticating a PIN Without Compromising the PIN ("Mat")
Re: Q: does this sound secure? (Thomas Wu)
Re: is NIST just nuts? (John Savard)
Re: Rijndael: making the "flaw" plainer (John Savard)
Re: RC6 royalty free or not? (John Savard)
Re: Comments on the AES winner (John Savard)
Re: is NIST just nuts? (John Savard)
Re: Rijndael test vectors (John Savard)
Re: Authenticating a PIN Without Compromising the PIN (Paul Rubin)
Re: Authenticating a PIN Without Compromising the PIN (Thomas Wu)
Re: My Theory... (John Savard)
Re: Democrats, Republicans, AES... (Albert Yang)
Re: Requirements of AES (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: My Theory... (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: Requirements of AES (JPeschel)
Re: Democrats, Republicans, AES... (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: 4 Oct 2000 00:04:09 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Tom McCune wrote:
> On a modern computer, it takes no additionally noticeable
> time to encrypt or decrypt to a 4096 bit RSA key than it
> does to a 1024 bit RSA key. So although it isn't really
> necessary to use the maximum potential of PGP by using a
> key larger than 3000 bits, there isn't really harm in doing
> so (except for backwards compatibility). I'm surprised
> that this performance myth continues.
As far as I can tell, it ought to be possible to take PGP 2.6.3ia
(the "internationalized" version of 2.6.2, with some extra bug fixes,
which has been available since 1996 on www.pgpi.org) and modify it
to generate and use 4096-bit RSA keys by making the following simple
changes to the source code:
==> In mpilib.h, change MAX_KEY_BITS from 2048 to 4096.
==> In randpool.h, change RANDPOOLBITS from 3072 to something larger
(otherwise the program will bomb during generation of a large key).
I chose a new value of 10240, and it seems to work, though this is
probably somewhat larger than necessary.
This isn't any sort of official patch: I don't work for NAI, I accept
no liability if the modified code doesn't work or has hidden weaknesses,
etc., etc. I'm just proposing this as a starting point for discussion
and experimentation. I would be very interested in any constructive
feedback.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3ia
Charset: noconv
Comment: Rich Wales's public keys at http://www.webcom.com/richw/pgp/
iQEVAwUBOdpznEm4X0z9+PxlAQF7Agf+KPd6nm8ij+mpAIcV3tGLL4F+NlYyhoEA
mPIfLrhviOjnq3rqnffoRvTbQDR7JStMbbe8tJHqapWYbo/k7TMaOwbwzSJBN9xF
9rqjjZUphjJ7n/xadzsnR/uM8A+L1TU6XS19TH8FljR0Hhn0s4rFMVG+HGQKQbkE
6wLSoiAhLt/ujIZxOh887Yu4UcmHraW0Ffs5S87nfJe4RPd/n5rzZzLvcS/iN/ep
J75HMnAmySbxx3E54tBBIxvEba1uBYj6lIiX1gnCQvo9T8yTylqhQZNNPps4E8Hi
gx3DKgRLpIa7JqKZx6vQUwzIaJuZPfzS19t5BHMTx4uBd18P7uDuPg==
=kt3+
=====END PGP SIGNATURE=====
------------------------------
From: "Mat" <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: Wed, 04 Oct 2000 00:16:11 GMT
Why can't you have the server generate a random number and give it to the
client. The client would then hash its pin with the number and return the
result to the server. The server would do the same and compare the results
to see if they match. The pin would never be sent over the network.
I thought that was the way secure email authentication worked or something?
I'm sure there are flaws in it but it may suit your need. There would be no
assurance that you were talking to the right server besides the network
address. I guess the server could be forced to authenticate through the
same method and verify that it had a copy of your password if that were
neccessary?
I'm thinking of using something like this in a client server system over the
Internet. If anyone has any comments on this form of authentication please
speak up. My security needs are not very heavy though and I am also
considering sending the passwords plain.
>Client Connects
>Server Generates Challenge Random #
>Client Sends Password Hashed with Challenge #
>Server Authenticates or Says OK
Matt
"Guy Lancaster" <[EMAIL PROTECTED]> wrote in message
news:8rd6d8$4a9$[EMAIL PROTECTED]...
> If it's possible, how could a protocol authenticate a user's
> PIN without revealing information that would make it
> relatively easy to determine the actual PIN value?
>
> PINs are commonly used to authenticate users of trusted
> machines but is there any way that they can be secure for
> use over untrusted networks? I'm beginning to think that
> the answer is no.
>
> Here's a scenario. We want to allow authorized users of a
> service to access that service over an untrusted network
> such as the Internet. We provide a small device that can
> connect via this network. These devices are not keyed
> to specific users and are readily accessible. Our server
> needs to authenticate the user but we cannot guarantee that
> the connection won't get redirected by a third party to
> another server for the purposes of gaining unauthorized
> access to our system. Thus our device needs to provide
> information that allows us to authenticate the user but
> does not allow an attacker's server to be able to determine
> the shared secrets.
>
> 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. I can find no way of
> authenticating a PIN without revealing enough information to
> crack it. Am I wrong?
>
> Guy
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 03 Oct 2000 17:13:29 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> 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).
> 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).
> 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.
As others have noted, this is vulnerable to a password-guessing attack
from an eavesdropper. In addition, since the server's secret is a
a password equivalent, somebody who reads the server's password file
can impersonate all the users.
Use a strong password protocol, like SRP or SPEKE. SRP, for example, has
a Java implementation (jdk102 or jdk11x) already in the distribution
which is free.
http://srp.stanford.edu/
http://www.integritysciences.com/
Incidentally, you should sign your applet, so that user's don't type
their passwords into a trojan horse applet.
--
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] (John Savard)
Subject: Re: is NIST just nuts?
Date: Wed, 04 Oct 2000 00:10:17 GMT
On Tue, 3 Oct 2000 08:32:07 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote, in
part:
>I believe there's some argument that the effective strength was only at
>about the 56-bit level anyway.
Yes, but so far the strength level is 65 bits, at least as of AC, 2nd
ed., so a 64-bit key would not have stretched things too far. And a
trivial fix - putting the IP and IIP where they could do some good,
after rounds 4 and 12 - would likely allow DES to support longer keys
and give back strength in return.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael: making the "flaw" plainer
Date: Wed, 04 Oct 2000 00:00:46 GMT
On Tue, 03 Oct 2000 21:23:47 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>What do you mean by 'having the Byte Sub in line'? (You
>have said that 'The Byte Sub step corresponds roughly to the
>f-function'.) Thanks.
Although the Byte Sub performs the same function as the f-function, it
does so in a different way. The f-function in DES acts on a copy of
one half of the block, and the result is only used to XOR with the
other half of the block.
On the other hand, the Byte Sub substitution actually changes the
bytes themselves as they move from plaintext to ciphertext. Like the
S-boxes in SAFER.
So instead of being "at right angles" to the line from a plaintext
byte to the same byte in the ciphertext, they are in the path of that
line.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: RC6 royalty free or not?
Date: Wed, 04 Oct 2000 00:02:02 GMT
On Tue, 03 Oct 2000 21:50:10 GMT, [EMAIL PROTECTED] (Sami J. Mäkinen) wrote,
in part:
>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.
No; RC5 is patented and requires licensing, and the same applies to
RC6. It was only subject to the conditions required of an AES
candidate - to be made available freely *if* selected.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Comments on the AES winner
Date: Wed, 04 Oct 2000 00:11:57 GMT
On Tue, 03 Oct 2000 21:26:50 +0300, Helger Lipmaa <[EMAIL PROTECTED]>
wrote, in part:
>...I had an equation for RSA I could write on the corner of the page...
True. Of course, it operates on large numbers, and the mathematical
operations involved were especially selected for non-invertibility.
With a block cipher, it is precisely the complexity of the combination
of simple operations that provides the security.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: is NIST just nuts?
Date: Wed, 04 Oct 2000 00:07:45 GMT
On Tue, 03 Oct 2000 18:02:16 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote,
in part:
>The NSA apparently designs even closer to the margin: the best known
>attacks by academics on Skipjack just barely miss being able to reduce
>the work factor below brute force keysearch. By that standard having
>a security headroom of 4 out of 10 rounds above the best nearly
>practical attack seems generous.
Since there are _dozens_ of mathematicians in the open community
working on cryptography - and _thousands_ doing so within the NSA,
they can get away with this sort of thing.
And, remember, SKIPJACK is Type 3. I _hope_ they are a bit more
cautious when it comes to Type 1 algorithms.
(As I recall, from a post here, Type 1 is for SECRET and TOP SECRET,
Type 2 is for other classified data, i.e., CONFIDENTIAL, and Type 3 is
for sensitive but unclassified.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Rijndael test vectors
Date: Wed, 04 Oct 2000 00:17:12 GMT
On Tue, 3 Oct 2000 23:11:41 +0100, "Brian Gladman"
<[EMAIL PROTECTED]> wrote, in part:
>A world I hope we can remove by getting the specification right on such
>matters.
I'm still miffed that the specification for Rijndael - even the
current version - does not exhibit the S-box. That it happens to be
the multiplicative inverse on GF(2^8) followed by a bitwise matrix
multiply is very nice background material, but prospective
implementers ought not to be expected to jump through hoops of
advanced mathematics.
Of course, one still needs to perform a simpler operation in GF(2^8)
to do the Mix Column step, but *that* operation is a straightforwards
one that is also done in computing CRCs, so the mechanical procedure
for it is commonly documented.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: 03 Oct 2000 17:27:34 -0700
"Mat" <[EMAIL PROTECTED]> writes:
> Why can't you have the server generate a random number and give it to the
> client. The client would then hash its pin with the number and return the
> result to the server. The server would do the same and compare the results
> to see if they match. The pin would never be sent over the network.
Unless there's a shared secret key between the client and server
that's incorporated into the hash, your protocol is vulnerable to a
brute force against the PIN by an attacker who knows the hash
function.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Authenticating a PIN Without Compromising the PIN
Date: 03 Oct 2000 17:21:36 -0700
Guy Lancaster <[EMAIL PROTECTED]> writes:
> If it's possible, how could a protocol authenticate a user's
> PIN without revealing information that would make it
> relatively easy to determine the actual PIN value?
>
> PINs are commonly used to authenticate users of trusted
> machines but is there any way that they can be secure for
> use over untrusted networks? I'm beginning to think that
> the answer is no.
The answer is yes - this problem has been solved a number of
times in different ways. What you want is a zero-knowledge proof
of the PIN, constructed so that passive and active adversaries
cannot do an off-line brute force attack (on-line attacks are
thwarted by throttling/limiting attempts). If you have no other
authentication factor, like a disk file or a smart card, then a
strong password protocol is what you're looking for. There are
lots of them - SRP, SPEKE, EKE, PAK, OKE, AMP, S3P, for starters,
so it's a matter of finding out which one(s) are most suitable
for your application, in terms of security, efficiency, licensing,
etc.
http://srp.stanford.edu/
http://www.integritysciences.com/
> Here's a scenario. We want to allow authorized users of a
> service to access that service over an untrusted network
> such as the Internet. We provide a small device that can
> connect via this network. These devices are not keyed
> to specific users and are readily accessible. Our server
> needs to authenticate the user but we cannot guarantee that
> the connection won't get redirected by a third party to
> another server for the purposes of gaining unauthorized
> access to our system. Thus our device needs to provide
> information that allows us to authenticate the user but
> does not allow an attacker's server to be able to determine
> the shared secrets.
Nearly all of these protocols require no additional PKI, like certs
and CAs, and they generally do secure key exchange as well.
> 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. I can find no way of
> authenticating a PIN without revealing enough information to
> crack it. Am I wrong?
>
> Guy
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
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] (John Savard)
Subject: Re: My Theory...
Date: Wed, 04 Oct 2000 00:20:18 GMT
On 3 Oct 2000 15:31:00 GMT, [EMAIL PROTECTED] (Thomas Pornin) wrote,
in part:
>The AES contest showed that the community knows how to design secure
>ciphers, we had 15 of them; the choice is merely marketing: the point
>of a standard is that people use it, so the winner had to be the most
>popular. Hence Rijndael.
One or two of the 15 initial applicants were less than secure, I had
thought. However, given the criterion for a 'break' is merely an
attack faster than brute force - and a cipher with 2^96 complexity for
the best attack is still "secure" by any practical standard - perhaps
that is true.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Wed, 04 Oct 2000 01:32:05 GMT
[snip]
> 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
I'm talking about margin of security with respect to decisions made.
Hmm, I can design a cipher that uses an XYZ structure, or I can design
one using the Feistel structure. Which is more secure? Well, since we
know nothing about the XYZ structure, we don't know what it's vulnerable
to, and so I would have to say that maybe the XYZ structure is more
secure academically, in terms of trust and confidence, I would probably
trust feistel more.
What's what I mean, margin of security with respect to how conservative
the design is.
If algorithm A with N rounds can be broken with M rounds, and algorithm
B has N1 rounds and can be broken with M1 rounds, then although not a
great comparison, a M/N compared to M1/N1 would tell you which is more
vulnerable.
Say 9 rounds of Serpent can be broken. 9/32 is not too bad. In terms
of percentage, that's roughly 28%. So 28% of it's rounds can be broken,
that's still 72% unbroken (keeping in mind also, round difficulty to
break in general is not a linear time or difficulty, but rather exp).
72% of the rounds not broken is the Serpent security margin.
Say 8 rounds of Rijndael is broken for the 128bit key. That's 8/10 or
80% of it's rounds. That leaves 20% of the rounds left as security
margin, that is what I'm talking about, this does NOT give me warm
fuzzies, not when I'm trying to secure my companies entire database...
Albert
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Wed, 04 Oct 2000 01:28:37 GMT
In article <#MUDhDZLAHA.250@cpmsnbbsa09>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> > 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.
Ouch... true... but I think 1024-bit is ultra conservative now. I
think 600 bits is risky and 768 is safe... so take Rijndael with 28
rounds that the same (idea) as RSA with 1024 bit moduli.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Wed, 04 Oct 2000 01:32:48 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> 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.
Sorry but I had to say it that way.
> > 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.
I read their papers. They said why Rijndael was picked, not why
Serpent or Twofish "were not" picked.
> 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.
Hmm security = most important goal.
> 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.
That is bs. Twofish key setup can be implemented about four different
ways off the top of my head... so which one is the slowest? See the
problem is you are comparing the wrong implementations of Twofish
against Rijndael. In Twofish I can do no precomputation (faster then
Rijndael), I can precompute just the sboxes, I can precompute the
sboxes and g function, I can make compiled code, etc... which one did
you use?
> 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.
Again which version of Twofish did you compare?
> Fourth, Serpent and Rijndael have the best hardware throughput,
> RC6 and Twofish have average throughput, and MARS is below average.
Again ...
> 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.
That's bs to. Twofish can be done with xors, ors and look ups. Same
with Rijndael.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Wed, 04 Oct 2000 01:36:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On 3 Oct 2000 15:31:00 GMT, [EMAIL PROTECTED] (Thomas Pornin) wrote,
> in part:
>
> >The AES contest showed that the community knows how to design secure
> >ciphers, we had 15 of them; the choice is merely marketing: the point
> >of a standard is that people use it, so the winner had to be the most
> >popular. Hence Rijndael.
>
> One or two of the 15 initial applicants were less than secure, I had
> thought. However, given the criterion for a 'break' is merely an
> attack faster than brute force - and a cipher with 2^96 complexity for
> the best attack is still "secure" by any practical standard - perhaps
> that is true.
Some of the 15 AES submissions were just not good ciphers. LOKI and
FROG come to mind as slow ciphers same with SAFER. I mean SAFER was
much too slow even if it was secure.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Wed, 04 Oct 2000 01:35:42 GMT
In article <8rdqle$mhv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> 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.
What attack on Twofish has a 16/11 advantage? The one by Knudsen that
he retracted two days later?
> 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.
Why not use a cipher you are sure it is informationaly secure. I mean
if DES was redesigned to use a 56-bit key but resilient to diff/linear
attacks I would be much happier, just for the warm fuzzy feeling.
> > 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.
See you people say Rijndael won because of speed, but you then
state "add more rounds". But look here stupid. If you add more rounds
YOU MAKE THE CIPHER SLOWER!!!!
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Requirements of AES
Date: 04 Oct 2000 02:04:16 GMT
Tom St Denis [EMAIL PROTECTED] writes, in part:
>In article <[EMAIL PROTECTED]>,
> Jim Gillogly <[EMAIL PROTECTED]> wrote:
>> 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.
>
>Sorry but I had to say it that way.
>
>> > 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.
>
>I read their papers. They said why Rijndael was picked, not why
>Serpent or Twofish "were not" picked.
>
>> 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.
>
>Hmm security = most important goal.
>
>> 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.
>
>That is bs...<snipped>
>> 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.
>
>Again which version of Twofish did you compare?
>
>> Fourth, Serpent and Rijndael have the best hardware throughput,
>> RC6 and Twofish have average throughput, and MARS is below average.
>
>Again ...
>
>> 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.
>
>That's bs to. Twofish can be done with xors, ors and look ups. Same
>with Rijndael.
Jim is summarizing the report, a report you should re-read.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Wed, 04 Oct 2000 02:07:05 +0000
Albert Yang wrote:
> Say 8 rounds of Rijndael is broken for the 128bit key. That's 8/10 or
> 80% of it's rounds. That leaves 20% of the rounds left as security
> margin, that is what I'm talking about, this does NOT give me warm
> fuzzies, not when I'm trying to secure my companies entire database...
Now say 6-round Rijndael is broken for the 128-bit key, or 60% of its
rounds. That leaves 40% overkill. <Now> do you feel warmer or fuzzier?
--
Jim Gillogly
Mersday, 13 Winterfilth S.R. 2000, 02:05
12.19.7.10.17, 13 Caban 20 Chen, First 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
******************************
