Cryptography-Digest Digest #822, Volume #12 Tue, 3 Oct 00 06:13:01 EDT
Contents:
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Shareware Protection Schemes (Paul Schlyter)
Re: It's Rijndael (Paul Schlyter)
Re: It's Rijndael (Mok-Kong Shen)
Re: It's Rijndael (Mok-Kong Shen)
Re: It's Rijndael (Mok-Kong Shen)
Re: is NIST just nuts? ("Sam Simpson")
Re: NIST Statistical Test Suite ([EMAIL PROTECTED])
Re: Hardware Implementation of DES (Mok-Kong Shen)
Re: is NIST just nuts? (Tim Tyler)
Re: is NIST just nuts? (Tim Tyler)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Problem question (Tim Tyler)
Re: Problem question (Tim Tyler)
Re: is NIST just nuts? (Helger Lipmaa)
Re: Hardware Implementation of DES (TY)
----------------------------------------------------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Tue, 03 Oct 2000 09:16:03 +0200
"John A.Malley" <[EMAIL PROTECTED]> wrote:
> Is there a "must-read" paper or a set of "must-read" papers on OAEP
> you recommend?
For an intro,
<http://www.rsasecurity.com/rsalabs/faq/7-10.html>
The seminal paper:
Mihir Bellare and Phillip Rogaway.
Optimal asymmetric encryption - How to encrypt with RSA.
Advances in Cryptology - EUROCRYPT '94, Lecture Notes in Computer
Science, Vol. 950, A. De Santis, ed., Springer-Verlag, 1995.
available online from
<http://www.cs.ucdavis.edu/~rogaway/papers/>
temporarily unavailable online from
<http://www-cse.ucsd.edu/users/mihir/crypto-research-papers.html>
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Shareware Protection Schemes
Date: 3 Oct 2000 08:31:45 +0200
> There is no private key in symmetric encryption algorithms such as
> Blowfish.
Well, if you intend to make the only key of a symmetric algorithm
public, where's the security?
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: It's Rijndael
Date: 3 Oct 2000 08:32:10 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> On Mon, 2 Oct 2000 18:16:58 +0200, Serge Paccalin
> <[EMAIL PROTECTED]> wrote, in part:
>
>> Just a question: since they chose a Belgian algorithm, will they
>> have the nerve to forbid its export?
>
> The export of the algorithm from Belgium is OK. Export of products
> *made in the US* _using_ that algorithm will, indeed, be restricted as
> per usual. Although the US restrictions are now not what they were.
NIST should be grateful that Belgium doesn't have US-like crypto
export restrictions....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 10:32:33 +0200
John Savard wrote:
>
> Although the choice of Rijndael came as a complete surprise to me, it
> did not come as a surprise to me that they chose the winner that:
>
> - required the least memory, and
>
> - ran the fastest
>
> given that all the algorithms were of satisfactory security.
>
> I hadn't paid close attention to how the algorithms fared in those
> respects. My own instincts were to go for as much security as
> possible, and I inclined towards Twofish - and MARS, despite recent
> concerns about its security. But I favored a modification to MARS that
> would have made it somewhat slower - and caused it to require
> significantly more memory.
Given the fact that speed and size are considered to
be very essential (perhaps a bit too essential in my view)
criteria, the choice of Rijndael seems to be very natural
to me, though I wouldn't be greatly surprised if Serpent
or Twofish were chosen instead. As I said previously
elsewhere, I personally prefer Rijndael (because of its
'simplicity', among other subjective points of view) even
though I am of the opinion that it has some scope of
improvements to better satisfy the needs of those users
for whom speed and size are not that critical.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 10:32:44 +0200
John Savard wrote:
>
> Jim Gillogly <[EMAIL PROTECTED]> wrote,
>
> >If a cipher has an "adequate" security margin against all known
> >attacks, then it is as good from a security standpoint as any
> >other cipher.
>
> I'm not sure if I can fully agree iwth that.
Note that all the bridges over which you probably drive
everyday are designed only with adequate safety factors.
They would all collapse under a sufficiently strong
unprecedented earthquake. (On the other hand, I personally
favour having the possibility of variable number of rounds,
which would take care of your wish cited below.)
> In my view, if they're going to call it "A Cryptographic Algorithm for
> the 21st Century" then it ought to remain adequate, during the whole
> term of the 21st Century (that is, up until December 31st, 2100) for
> all purposes - which implies, to my mind, that anything encrypted with
> it should remain unbreakable for at least another 150 years (barring
> significant advances in human longevity).
[snip]
> Besides MARS, I liked the multiple layers of the f-function in
> LOKI-97, the high nonlinearity of FROG, and the deep logical mesh of
> MAGENTA: those three ciphers may have been flawed, but the ideas they
> contained, with a little work, had promise. Thus, my attitude is
> simply one of "try harder"; but that doesn't apply specifically to
> Rijndael compared to the other finalists.
Recently I attempted to look at MAGENTA but couldn't
locate any more its documentation. Could you help?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 10:32:40 +0200
Jim Gillogly wrote:
>
[snip]
> Given their resources, I think NIST did an outstanding job
> of balancing the pros and cons of the ciphers, of taking
> into account all the comments they received, of keeping
> a satisfying amount of the process open, and of sticking
> to their announced schedule. Their report does them credit,
> and while some of us may take issue with the importance given
> to any particular criterion I think most of us would be
> inclined to give them a rousing ovation for a job well done.
Very well said. (Interesting to compare however the title of
another thread.)
M. K. Shen
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 3 Oct 2000 09:05:49 +0100
Erm, I thought that Serpent was generally perceived to be the most
secure candidate? And you want Twofish to win? Why? Don't you
agree with the suggestion that Twofish was too hard to properly
analyse in the timeframe?
Seriously Tom, your favorite cipher may not have won, but get over
it.
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8raips$vsd$[EMAIL PROTECTED]...
> As if that was picked... From what I understand it's not at all
close
> to the securest block cipher. Will aes specify that cipher with
more
> rounds? What a shame...
>
> I demand a recount! Twofish should have won!
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Tue, 03 Oct 2000 08:13:35 GMT
Could anyone help compile the code on a Pentium machine? I am using
VC++6.0 but i am ready to switch to something else if it is easier.
I have tried to modify the code so that it works but i think it is a bit
out of my league.
Thank you in advance for your help.
Brice.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Peter J. Acklam) wrote:
> [EMAIL PROTECTED] writes:
>
> > Has anyone got code for the function erfc() that i could include
> > in the software as this function does not seem to be available
> > when using Visual C++ 6.0.
>
> Do a search at Netlib: http://www.netlib.org
>
> Peter
>
> --
> Peter J. Acklam - [EMAIL PROTECTED] -
http://www.math.uio.no/~jacklam
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hardware Implementation of DES
Date: Tue, 03 Oct 2000 10:41:04 +0200
Carpe Diem wrote:
>
> I have to design a chip for a project and I was thinking to implement the
> DES encryption algorithm. Does anybody have any references for me to read?
I vaguely remember that a couple of years ago a post in
this group offered to provide DES coded in VHDL. If you
could search the archived news, that might eventually
be useful to you.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 08:32:07 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: They may have cleaned come some things up. But are your forgetting the
: key size was lowered to be 56 bits. That alone made it easy for
: them to break.
I believe there's some argument that the effective strength was only at
about the 56-bit level anyway. According to the story, reducing the size
of the keyspace reflected the properties of the underlying algorithm, and
didn't really make the system weaker than it already was.
Of course, sterengthing it to allow it to take advantage of a full 64-bit
keyspace would probably also have been a possible resolution.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 08:37:59 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: Albert Yang <[EMAIL PROTECTED]> wrote:
:> It wasn't the fastest on hardware (Serpent, Rijndael)
: Hardware is *not* where we will see alot uses of it.
I thought that was a pretty central design consideration.
AES will be used in smart cards and the like.
For example, http://www.ibutton.com/ibuttons/java.html has hardware
acceleration for encryption.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Tue, 03 Oct 2000 10:59:21 +0200
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
> Bad hash functions allow easy forgeries under all of these
> systems. Forgeries are unacceptable.
With odd exponents, bad hash functions tend to allow forgery of a
very small subset of messages. With even exponents, bad hash
functions allow factorisation of the modulus then signature of any
message. At least that is what happens with the recent attacks on
ISO 9796-1 and ISO 9796-2 padding schemes. So in some sense,
signature with odd exponents are arguably more resilient.
This resilience comes at the cost of security that we do not know
how to reduce to factoring.
> The solution is to stop using bad hash functions.
Agreed. In particular, this is a much sounder solution than using
higher public exponent without justification. Unfortunately, I know
no accepted padding standard with provable security.
If I could propose a standard, it may be a FDH[4] or PSS[5] scheme
with exponent 2 (or 3 if marketing considerations rule), and SHA1
or RIPEMD (or maybe some arithmetic hash scheme is there is a
security proof) as the required hash.
But AFAIK the FDH concept, or much less PSS, is not part of any
ISO standard; is there one in P1363 or PKCS ?
NB: One problem with PSS is the need for a random number generator
in the signer, and room for a subliminal channel. Replacing the RNG
with a hash of the message reverts to FDH, if I get it correctly.
Francois Grieu
[4] M. Bellare and P. Rogaway: Random oracles are practical:
A paradigm for designing efficient protocols. Proceedings of
the First Annual Conference on Computer and Communications
Security, ACM, 1993.
Full paper online at:
<http://www-cse.ucsd.edu/users/mihir/papers/ro.html>
[5] M. Bellare and P. Rogaway: The exact security of digital
signatures: How to sign with RSA and Rabin
Advances in Cryptology - Eurocrypt 96 Proceedings, Lecture Notes
in Computer Science Vol. 1070, U. Maurer ed, Springer-Verlag, 1996.
Full paper online at:
<http://www-cse.ucsd.edu/users/mihir/papers/exactsigs.html>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Problem question
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 08:54:15 GMT
Ernest Dumenigo <[EMAIL PROTECTED]> wrote:
Puzzle:
: ORSUU ABIMR AEHNS ENSUV ADKOR ADEGM EEINN EMNVY EELSS S
: Our submarine has ENSUV ADKOR ADEGM nine enemy vessels
->Our submarines have sunk ADKOR ADEGM nine enemy vessels
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Problem question
Reply-To: [EMAIL PROTECTED]
Date: Tue, 3 Oct 2000 08:55:42 GMT
Ernest Dumenigo <[EMAIL PROTECTED]> wrote:
Puzzle:
: ORSUU ABIMR AEHNS ENSUV ADKOR ADEGM EEINN EMNVY EELSS S
: Our submarine has ENSUV ADKOR ADEGM nine enemy vessels
->Our submarines have sunk or damaged nine enemy vessels
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 03 Oct 2000 14:08:41 +0300
David Blackman wrote:
> In custom hardware, Rijndael requires a lot less gates than Twofish and
> runs somewhat faster. One of the guys doing hardware evaluation of the
> finalists said something like "As a hardware guy, i really like
> Rijndael. As a crypto guy, i've got my doubts." (It's on the AES
> website, somewhere :-)
>
> I think Rijndael might be a bit faster in software than Twofish, if you
> do the same extreme optimisations the Twofish team did. I don't know of
> anyone who's tried this yet, but it will certainly happen now.
See http://www.tml.hut.fi/~helger/aes, in particular table.html and the
publication (Aoki, Lipmaa) refered from there. In a nutshell, we
implemented 4 AES finalists (all minus Serpent) on the Pentium II. Did
very extensive optimisation. Rijndael got 232 cycles, Twofish got 277
(updated numbers). Twofish's implementation is 15% better than the 'highly
optimised' implementation of the Twofish team (here we compare to the one
that does not use self-modfying code). Even more interesting, during
Rijndael encryption, in average 2.6 uops are executed simultaneously.
Taking in account all the limits of Pentium II, it is a superb result and
shows something about the cipher.
And yes, the implementations were done late the last year/early this
year. Read the publication for motivations, explanations etc.
Helger
http://www.tml.hut.fi/~helger
------------------------------
From: TY <[EMAIL PROTECTED]>
Subject: Re: Hardware Implementation of DES
Date: Tue, 03 Oct 2000 11:26:04 +0200
Reply-To: [EMAIL PROTECTED]
On Tue, 03 Oct 2000 10:41:04 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>I vaguely remember that a couple of years ago a post in
>this group offered to provide DES coded in VHDL.
check this :
http://www.yordas.demon.co.uk/crypto/
http://www.yordas.demon.co.uk/crypto/pipelined-des.tar.gz
T.Y.
------------------------------
** 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
******************************
