Cryptography-Digest Digest #830, Volume #12 Tue, 3 Oct 00 18:13:00 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: Shareware Protection Schemes (Darren New)
Re: Comments on the AES winner (Anton Stiglic)
Re: is NIST just nuts? (Tim Tyler)
simple equation for Rijndael (Anton Stiglic)
Re: Democrats, Republicans, AES... (Mok-Kong Shen)
Re: Looking Closely at Rijndael, the new AES (Tim Tyler)
Re: Advanced Encryption Standard - winner is Rijndael (nemo outis)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Tom McCune)
Re: My Theory... (Tom St Denis)
Re: Need help: considerations for IV and Keysetup (Tim Tyler)
Q: does this sound secure? ("William A. McKee")
Re: Rijndael test vectors (Roger Schlafly)
Re: Requirements of AES (Tim Tyler)
Re: It's Rijndael (David Schwartz)
Mathematical Problem ("Saurabh Tavildar (97007024)")
Re: Advanced Encryption Standard - winner is Rijndael (Mok-Kong Shen)
RC6 royalty free or not? (Sami J. M�kinen)
Re: Democrats, Republicans, AES... (Albert Yang)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Ed Kubaitis)
Re: Do not vote for those communistic policies of Al Gore .... (Albert Yang)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 03 Oct 2000 22:23:06 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > > Each session uses a (different) secret seed for the PRNG.
> > > > (I use effectively more key material, as said in a previous
> > > > follow-up.)
> > >
> > > Does your method requires a separate secure channel for
> > > transporting the per-message keys? How do the sender
> > > and receiver know which key to use?
> >
> > They get the material with the same channel at the
> > same time. Send some longer material, one part for the
> > encryption key, the other part for the seed. That
> > seed is for the whole session, which may consist of
> > a number of messages.
>
> So the scheme is only appropriate when a new key will be transported
> for each session? Note that a conventional block cipher and
> chaining mode can support arbitrarily many sessions and messages
> with a single key.
Then you send the secret seed with that 'single' key.
I don't understand what is the problem that you see here?
> > > [...]
> > > > > Hard to sell exposing the key as a good thing.
> > > >
> > > > Sorry, the above sentence is difficult for me (foreigner)
> > > > to understand.
> > >
> > > Hard to take that seriously.
> >
> > Does that constitute a concrete answer that I requested
> > (see the part you snipped)?? (A yes/no is anyway needed.
> > And some explanations.)
>
> What is needed is a serious attempt to understand the material.
But you don't answer my question whether introduction
of permustaion reduces or enhances the strength, i.e.
produces a negative or positive effect. If your attack
is good then you should be able to firmly answer that it
reduces the strength. But you seem so far to avoid that
question.
M. K. Shen
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Shareware Protection Schemes
Date: Tue, 03 Oct 2000 20:19:10 GMT
Ichinin wrote:
> > I saw an interesting mechanism once that just put the credit card number
> > used to pay for the software into the "About" box. Encrypted in the
> > executable, of course.
>
> How does it work? Does it have a PK that encrypts Name+CC
> number, ships it to the manufactorer, which returns a
> valid key?
No. The point was that anyone you gave the registered software to could see
your CC#. It was just enough of an impediment to keep someone from widely
distributing the software.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Comments on the AES winner
Date: Tue, 03 Oct 2000 16:43:04 -0400
Helger Lipmaa wrote:
>
> John Savard wrote:
>
> > On Mon, 02 Oct 2000 19:05:47 -0400, "Douglas A. Gwyn"
> > <[EMAIL PROTECTED]> wrote, in part:
> > >Anton Stiglic wrote:
> >
> > >> In a rump session talk at Crypto 2000, N. Ferguson
> > >> (I believe it was) came up with an equation, in GF(2^8)
> > >> I believe, stating that if one can solve this equation
> > >> one can break Rijndael encryption. ...
> > >> Someone knows what the equation was?
> >
> > >What's the point? *Any* block cipher can be expressed in
> > >such an equation. It doesn't imply practical solvability.
> >
> > True. However, if it was possible to actually write the equation on a
> > blackboard (think of what the corresponding equation for DES would
> > look like) I suppose that could be, however invalidly, _perceived_ as
> > grounds for concern.
>
> ...I had an equation for RSA I could write on the corner of the page...
But that equation has been studied since the time of Fermat,
maybe even before.
--Anton
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 20:19:07 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] wrote:
:> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> : [EMAIL PROTECTED] wrote:
:> :> Albert Yang <[EMAIL PROTECTED]> wrote:
:>
:> :> : [Twofish] wasn't the most secure or had the most security margain
:> :> : (Serpent wins that)
:> :>
:> :> I think this is true if you assume that additional rounds beyond
: the
:> :> best known attack result in more strength. More rounds certainly
: help
:> :> prevent some attacks - but can make little difference to other
: ones.
:> :>
:> :> We probably can't say with very much confidence which out of
: Serpent,
:> :> Twofish, Rijndael has the "most security margin" until there are
:> :> better attacks on two of them.
:>
:> : Yeah but the idea is that known attacks are used as a metric in the
:> : absense of supreme enlightenment. Serpent and Twofish are secure
:> : against linear, differential, truncated differential, etc.. attacks
:> : whereas Rijndael is quasi-pseudo-weak to a known attack.
:>
:> You're blinding me with science here. What "quasi-pseudo-weakness"
:> do you refer to?
: Check out the "linear-sums" square attack by the Twofish team (on the
: counterpane website).
I believe that describes attacks on reduced round variants. Is that
what "quasi-pseudo-weak" means? You know that there are attacks on
reduced round versions of Serpent and Twofish as well?
: Yeah, but given all our advances in crypto we can barely break 9 rounds
: of Serpent because it was designed to resist these attacks. Rijndael
: suffers 8 of 10 rounds. [...]
``For 128-bit keys, 6 or 7 out of the 10 rounds of Rijndael have been
attacked, the attack on 7 rounds requiring nearly the entire codebook.''
>From http://csrc.nist.gov/encryption/aes/round2/r2report.pdf
There's no mention of a break of 8 rounds of the 128-bit key Ridndael.
If you know of such an attack, that would be interesting.
I believe section 3.2.2 of that document discusses the idea that
a numerical ratio of attacked rounds to total rounds provides a useful
measure. They seem quite critical of the idea overall.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: simple equation for Rijndael
Date: Tue, 03 Oct 2000 16:45:05 -0400
At the rump session of Crypto 2000,
N. Ferguson presented a nice relatively
short equation
which if we could solve would let us
break Rijndael's symmetric scheme.
Someone knows what that equation was?
Thanks,
Anton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Tue, 03 Oct 2000 23:07:38 +0200
Albert Yang wrote:
>
[snip]
> What I would have done is this, kept only the ones with "high level of
> security margain" and thrown out the rest. This takes into
> consideration, inheritance, pedigree, structure, "new math" etc..
> (Security was the first criteria right?)
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]
> Suppose that within the 90 day public comment period, someone breaks 10
> round Rijndael... what then? Since NIST has already said their views
> concerning a "hot backup", then where do we go from there? Restart the
> proposal? Use twofish, or Serpent, or RC6 or MARS? What?
>
> I think within the next 5 years, we will see a break against 10 round
> Rijndael, and given the fact that the NIST didn't even ask the standard
> to be Rijndael @ 16 rounds, I think it's a big mistake...
I have many times suggested allowing variable number of
rounds. That would have solved your problem basically.
Another way is to go like 3DES.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 20:31:40 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (John Savard) wrote, in part:
:>this is by analogy, which may be flawed, with
:>results on different block ciphers like DES,
: In the event this was too obscure a remark, I shall be explicit: Table
: 12.14, on page 289, AC 2nd edition.
This table covers the number of known, chosen, etc. plaintexts required
to attack reduced round variants of DES with differential cryptanalysis.
Some round numbers appear to be "sweet spots", with more resistance than
those on either side.
Since NIST examined resistance to differential cryptanalysis - and
didn't find any significant problems - I think it's safe to assume
that a direct differential attack on the algorithm as specified will
fail; so however many rounds are used are sufficient against this attack -
even if they are not at a point offering the best ratio of rounds to
resistance against it.
There's also the question (which you raise) of the validity of the
analogy. DES is "a bit different in structure" to Rijndael. It's not
immediately clear to me whether such an analogy is applicable.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Crossposted-To: alt.security.scramdisk
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 20:56:35 GMT
Thanks. I guess "security through obscurity" is a workable solution (in
the sense of another layer of protection beyond the core algorithmic layers)
if you have your own sufficiently large "captive review community" of
mathematicians, computer scientists, et al. to review/test your systems.
Regards,
In article <uS1uNOXLAHA.322@cpmsnbbsa09>, "Joseph Ashwood" <[EMAIL PROTECTED]>
wrote:
>> But let me then ask a related question. Is there any good public domain
>info
>> (speculative or otherwise) discussing what would make currently available
>> algorithms (e.g., Rijndael, its AES rivals, Blowfish, and so forth)
>> *unsuitable* for secrecy levels of confidential and up?
>
>Before I go in depth on this, first let me say that I have no clearance
>level designated by the government (at least none that I am aware of), I
>have no relationship with the government, and all statements made in here
>are guesses that I have made, the accuracy or lack thereof is an artifact of
>lack of knowledge.
>
>Lack of trust. Also because the NSA trusts it's own internal designs, and
>has less trust in the outside world, they add the protection of obscurity.
>They can afford to do that because they have a very large number of
>presumedly great mathematicians dedicated to doing the NSA's bidding.
>Outside of that we can make guesses based on what has been published, for
>example with the publication of KEA and Skipjack there cam information that
>the combination is a type II member of a class of fucntions that includes
>type I algorithms also. I'm fairly certain that the requirements go
>something like:
>Key space: 2^128 - 2^256 (probably given specifically for each design)
>Differential: 2^120 - 2^200
>Linear: 2^120 - 2^200
>Complexity : whatever
>Attack X (which we haven't found yet): 2^100-2^160
>etc
>Feeling: The CO must feel that it is good
>
>I'm sure there are other requirements that I just haven't put in, and the
>limits are probably tightened to taylor the design for a specific purpose.
>For example the presidents phone book (with associated personal notes) would
>be protected by a "minimal" cipher, and something like Rijndael would
>doubtless be usable. However the book of America's deepest darkest secrets
>would doubtless be covered by something very substantial, missing the
>maximum acceptable values by very small amounts. It would also not surprise
>me if there is a group that is used basically as an algorithm oracle, and
>several other groups that examine the oracle output, these now well analyzed
>ciphers would then be stored until a project came along requiring those
>particulars, very similar design to the public worlds Engineering-QA
>relationship.
> Joe
>
>
------------------------------
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 03 Oct 2000 21:06:33 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <8rd7ef$5e1$[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
<snip>
>Having said this though, I think i agree with you though, using keys
>bigger than 1024-bit is equal in stupidity to iterating DES 128 times.
>It reduces performance so much, its not worth using.
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.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.8
Comment: My PGP Page & FAQ: http://www.McCune.cc/PGP.htm
iQEVAwUBOdpK+jYk/PXew/BzAQHejgf+KoR4seeP2bm01Uz5q4W3YSJAHKV5YON5
YfOEb2Gp/bcJiFmvSJ8LHmh7ghIiCOWG5orm+TRA5zuTA/HlB/rJ+MPGCYzc4gP4
h+hcHiwUw47n/CULSGVs4ER+pURCNSGpxoBpog29rej+/d2y6HEF+lbkNLqBGpjc
XfOXymnV8xR3WMTRs3vXp2gNIQs3mwp2343JU/Mvupt6r5Lm92zeQnKnEepsqYu/
exddlkrourc+epDRX+N4fVuAU2scU9rwjHaI8EKf0hm1wc6kHeEwe6wIABTUB1Pq
z1q0yXViJTzExAWlE/2hr4fEO7CDtgWi3il3W4nXZ6ysAWVjXzpXng==
=mHe7
=====END PGP SIGNATURE=====
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Tue, 03 Oct 2000 20:58:41 GMT
In article <xzqC5.27663$Cl1.609796@stones>,
"Brian Gladman" <[EMAIL PROTECTED]> wrote:
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8rd30n$1ag$[EMAIL PROTECTED]...
> > In article <8rcu3k$i91$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Thomas Pornin) wrote:
> > > According to Tom St Denis <[EMAIL PROTECTED]>:
> > > > So what? The primary concern is security, not speed.
>
> [snip]
> > > 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.
> >
> > True, but remember that those subtle flaws in Rijndael parallel the
> > flaws in using a 56-bit DES key 30 years ago.
>
> It is hard to see the reduction of the DES key from 64 to 56 bits as
subtle
> but I agree that it was :-)
See we might say "oh Rijndael is secure now" but then 10 years later
when AES is in 1 billion devices...
While true we may not know if Serpent is actually secure, there is a
way higher prob that Serpent is more secure then Rijndael. I would
argue Twofish is more secure because of it's balanced design and keyed
sboxes.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Need help: considerations for IV and Keysetup
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 20:45:06 GMT
[EMAIL PROTECTED] wrote:
: I am currently writing a WinNT kernel driver to support encryption for
: scsi tape drives(e.g. dat drives). [...]
You /might/ like to steal some ideas from Mercy:
http://www.hedonism.demon.co.uk/paul/mercy/
The Mercy paper:
http://www.hedonism.demon.co.uk/paul/mercy/mercy-paper/node1.html
...discusses problems with generating (and storing) IVs. Paul's solution
is somewhat radical - and it is unlikely you will be able to adapt it
directly to an AES candidate, though.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Q: does this sound secure?
Date: Tue, 03 Oct 2000 21:14:41 GMT
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.
Is there any advantage to using SHA instead of MD5?
I also have a registration dialog box in the client that asks for a new user
id and password. The data is hashed as in 2 and the user id and hash key
are sent directly to the server to be added to the password file. Does this
compromise security?
TIA,
William A. McKee.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Rijndael test vectors
Date: Tue, 03 Oct 2000 14:25:06 -0700
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.
> You will not be surprised to know how often I have 'debugged' other people's
> code because of this!
I don't doubt it.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 20:53:06 GMT
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:
``NIST selected Rijndael as the proposed AES algorithm at the end of a
very long and complex evaluation process. During the evaluation, NIST
analyzed all public comments, papers, verbal comments at conferences,
and NIST studies and reports. NIST judged Rijndael to be the best
overall algorithm for the AES.
``Rijndael appears to be consistently a very good performer in both
hardware and software across a wide range of computing environments
regardless of its use in feedback or non-feedback modes. Its key
setup time is excellent, and its key agility is good. Rijndael�s
very low memory requirements make it very well suited for
restricted-space environments, in which it also demonstrates excellent
performance. Rijndael�s operations are among the easiest to defend
against power and timing attacks. Additionally, it appears
that some defense can be provided against such attacks without
significantly impacting Rijndael�s performance. Rijndael is designed
with some flexibility in terms of block and key sizes, and the algorithm
can accommodate alterations in the number of rounds, although these
features would require further study and are not being considered at
this time. Finally, Rijndael�s internal round structure appears to have
good potential to benefit from instruction-level parallelism.
``There are many unknowns regarding future computing platforms and the
wide range of environments in which the AES will be implemented.
However, when considered together, Rijndael�s combination of security,
performance, efficiency, implementability, and flexibility make it an
appropriate selection for the AES for use in the technology of
today and in the future.''
http://csrc.nist.gov/encryption/aes/round2/r2report.pdf
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 14:28:46 -0700
Scott Fluhrer wrote:
> > As an imperfect analogy to show why this is not so, think of a one time
> > pad. If you know the first X bytes of plaintext and the first X bytes of
> > ciphertext, you can produce a key that would produce that ciphertext for
> > that plaintext. However, that key is no more likely than any other to
> > correctly decrypt the next byte.
> However, it's not a one time pad. Assuming that you do find such a 256 bit
> key in rather less than 2^128 work, and further assuming (as per David
> Hopwood) there are about 2^128 such keys, then you have found the correct
> key with probability 2^-128, and with less than 2^128 work, this is better
> than brute force...
However that assumption was not stated, in fact David Hopwood
specifically stated the opposite of that assumption. Finding a key that
produces such an encryption is 2^128 easier than actually finding the
correct key. So doing that would not be equivalent to breaking Rijndael.
Read David Hopwood's original post and John Savard's response. David
Hopwood is correct and John Savard is incorrect (if you take him
literally).
DS
------------------------------
From: "Saurabh Tavildar (97007024)" <[EMAIL PROTECTED]>
Subject: Mathematical Problem
Date: Wed, 4 Oct 2000 01:29:12 +0530
Hi there
I am a senior undergraduate student of the Indian Institute of Technology,
Bombay and am presently working on my undergraduate thesis on "Error
Control Codes applied to Public Key Cryptosystems". I am presently
studying issues related to public key cryptosystems and am on the lookout
for a moderately complex problem that can be solved in a period of around
8 months.
I'd prefer a theoretical problem as my interests lie in the same. I have a
descent background in mathematics, information theory and
communication (maths olympiad levels).
anyone with suggestions of a problem which you think i could solve please
reply quickly.
Thanks in advance.
Saurabh.
* Saurabh Tavildar
* Final year Undergraduate
* Department of Electrical Engineering
* Indian Institute of Technology, Bombay
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 23:54:51 +0200
nemo outis wrote:
>
> Thanks. I guess "security through obscurity" is a workable solution (in
> the sense of another layer of protection beyond the core algorithmic layers)
> if you have your own sufficiently large "captive review community" of
> mathematicians, computer scientists, et al. to review/test your systems.
Indeed. This was stated in the citation of a paper of a
scientist that I reproduced in the group some time back.
M. K. Shen
------------------------------
Subject: RC6 royalty free or not?
From: [EMAIL PROTECTED] (Sami J. M�kinen)
Date: Tue, 03 Oct 2000 21:50:10 GMT
=====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.
Regards,
Sami J. M�kinen / [EMAIL PROTECTED]
- ---
SBC Archiver homepage: www.geocities.com/sbcarchiver
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Get my key from certcerver.pgp.com: "Sami J. M�kinen"
iQA/AwUBOdo3FUXlu0hQpi+BEQJS+ACg8a8rQ5sgrHW8a8+VvTDHXND5NyAAn1wQ
Y1hA9XHF8Ab95C/N44NdAjq5
=k5YI
=====END PGP SIGNATURE=====
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Democrats, Republicans, AES...
Date: Tue, 03 Oct 2000 21:54:34 GMT
<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...
Albert
------------------------------
From: Ed Kubaitis <[EMAIL PROTECTED]>
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 03 Oct 2000 16:56:43 -0500
Tom McCune wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In article <8rd7ef$5e1$[EMAIL PROTECTED]>, Simon Johnson
> <[EMAIL PROTECTED]> wrote:
> <snip>
> >Having said this though, I think i agree with you though, using keys
> >bigger than 1024-bit is equal in stupidity to iterating DES 128 times.
> >It reduces performance so much, its not worth using.
>
> 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.
> ...
????
Maybe I'm missing your point here, but here's output from the openssl
0.9.5a (no RSAref) benchmark on a 500 MHz Pentium III:
sign verify sign/s verify/s
rsa 512 bits 0.0047s 0.0005s 211.4 2024.3
rsa 1024 bits 0.0257s 0.0015s 38.8 687.3
rsa 2048 bits 0.1566s 0.0048s 6.4 209.7
rsa 4096 bits 1.0633s 0.0167s 0.9 59.8
By these numbers you seem to have a very laid-back notion of
what constitutes "noticeable", certainly not one likely to
be shared by busy SSL server operators.
==========================
Ed Kubaitis ([EMAIL PROTECTED])
CCSO - University of Illinois at Urbana-Champaign
------------------------------
From: Albert Yang <[EMAIL PROTECTED]>
Subject: Re: Do not vote for those communistic policies of Al Gore ....
Date: Tue, 03 Oct 2000 21:59:16 GMT
Vote for Harry Browne!!! You KNOW he's for open borders and heavy
crypto.. Actually, I don't see that on his platform, I will email him.
Bush is better than Gore though, (not by much). Gore, wants to tax,
spend, reduce rights, and take away my guns. Bush, he's just a moron,
which is always slightly safer... An innert president is better than a
communistic one...
Albert
------------------------------
** 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
******************************
