Cryptography-Digest Digest #813, Volume #12 Mon, 2 Oct 00 12:13:00 EDT
Contents:
Re: Choice of public exponent in RSA signatures (Bodo Moeller)
Re: Why is TwoFish better than Blowfish? (SCOTT19U.ZIP_GUY)
Re: CRT and RSA 2 (Francois Grieu)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
RE: Ciphers and Unicode ("Manuel Pancorbo")
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Choice of public exponent in RSA signatures ("John A.Malley")
Project: Digital Signing and Encrypting Application (Patrick Reynolds)
Re: CPU's aimed at cryptography (JCA)
Re: AES annoucement due Monday 2nd October (Bruce Schneier)
Re: NIST Statistical Test Suite ("Cristiano")
Re: Adobe Acrobat -- How Secure? (Jonathan Thornburg)
It's Rijndael (David Lesher)
Re: It's Rijndael (Quisquater)
Re: It's Rijndael (Helger Lipmaa)
Re: It's Rijndael (Ed Kubaitis)
Re: It's Rijndael (Quisquater)
Re: It's Rijndael (David Lesher)
RE: Ciphers and Unicode ("Manuel Pancorbo")
Re: It's Rijndael (David Lesher)
Re: It's Rijndael (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Choice of public exponent in RSA signatures
Date: 2 Oct 2000 13:14:19 GMT
Thomas Pornin <[EMAIL PROTECTED]>:
>> I'm trying to understand why so many professionals swear by it !
> RSA-based PGP used 65537. This is enough to create fashion.
Wrong. PGP 2.x usally uses e = 17, where e is made larger if this
is necessary to make it relatively prime to both p - 1 and q - 1.
Also larger bit lengths can be requested at the command line, but this
additional parameter is not documented.
--
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Why is TwoFish better than Blowfish?
Date: 2 Oct 2000 13:17:28 GMT
[EMAIL PROTECTED]=NOSPAM (Arturo) wrote in
<[EMAIL PROTECTED]>:
>
> Nope. Blame the author because he did put the names. I just said
>"blame" in an humorous sense. Of course, he might be working for the
>NSA, and adopted the name after their suggestions. I could be working
>myself for the NSA (just in case I am: please get me a salary raise).
I guess this explains why you never replaced your RLE with a bijective
RLE which would be more efficent. If you work for the NSA one of
your goals matches one of theirs. That is to keep people using
poor compression so that ciphers which use a compression stage
are easy to break.
>
>> There are a lot of conflicting requiremesnts. For one make it
>>secure but make it fast. For my purposes secure is a much more
>>valuable requirement. The problem is you really can't measure security
>>becasue what is secure today is insecure tomorrow.
>
> Grantes. But you can�t wait till tomorrow if you need it today.
> DES
>has awaited replacement for too long. And since nobody can guess the
>future, all we can do is test algorithms with the best techniques
>available today. Both TripleDES and IDEA are quite robust, so I could
>choose IDEA which is faster.
>
> Yeah, you can prove that CAST is 10^10 times stronger that IDEA.
> But if
>that means that it would take 10^50 years to break it instead of 10^40,
>that�s overkill.
>
I don't think you can prove CAST or IDEA would take more than one year
to crack unless that same "proof" is based on some weak assumption that no
underlying break is in either system. If your proof is based on some
hand waving evidence of one using a blind key search. We could prove
some versions of Engima are still safe. If it was not for the fact
we know they are not.
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: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: CRT and RSA 2
Date: Mon, 02 Oct 2000 15:26:40 +0200
Soeren Gammelmark <[EMAIL PROTECTED]> asked how to derive the formulas
used for secret-key RSA calculation with the CRT :
> Have can you deduce:
> m1 = c ^ (d mod (p - 1)) mod p and m2 = c ^ (d mod (q - 1)) mod q
> from m = c ^ d mod n ?
We can write d = d % (p - 1) + floor(d/(p-1)) * (p-1)
and thus c ^ d = (c ^ (d % (p - 1))) * ((c ^ (p-1)) ^ floor(d/(p-1)))
In the (general) case that c is not a multiple of p, since p is prime,
we have c ^ (p-1) = 1 mod p and thus, taking the above mod p,
c ^ d = c ^ (d % (p - 1)) mod p
In the (unlikely) case that c is a multiple of p, then obviously
the same holds true since both sides are multiple of p.
Francois Grieu
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 15:39:11 +0200
[EMAIL PROTECTED] (Bodo Moeller) wrote:
> PGP 2.x usally uses e = 17, where e is made larger if this
> is necessary to make it relatively prime to both p - 1 and q - 1.
Are you sure ? Casual look at the user interface tells me PGP 2.63
by default use odd e of at least 17 bits (that is, at least 2^16+1).
Comments in the source seem to confirm it.
Indeed PGP 2.63 does not use fixed e, and ajusts it after choosing
the primes p and q.
Francois Grieu
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: Ciphers and Unicode
Date: Mon, 2 Oct 2000 15:11:18 +0200
Ray Dillinger <[EMAIL PROTECTED]>
> Has anyone looked at Unicode seriously, and how it will interact
> with cipher software?
>
Well, my experience is very bad in this sense. I need to use UTF8 for other
languages but PGP(v.6) rifuzes to encryt/sign in other code page out of
ASCII or ISO-8859-1.
Well be there a solution?
Manuel Pancorbo
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 16:06:28 +0200
Francois Grieu <[EMAIL PROTECTED]> wrote:
> Are you sure ? Casual look at the user interface tells me PGP 2.63
> by default use odd e of at least 17 bits (that is, at least 2^16+1).
> Comments in the source seem to confirm it.
On second though I am not so sure. The user interface of FatMacPGP.263
does propose me 17 bits of e by default, and does generate keys
with e = 2^16+1 when I do nothing special. Comments in the source code
on one hand tell me the value taken from the user interface is the number
of bits, and on another tell me the default and minimal value for the
number of bits is 5 bits and that it can yield e = 17. Maybe the
default size of e is not the same across all the 2.x versions ?
I wonder how many PGP keys around have e = 21. Would not be a big deal,
though.
Francois Grieu
------------------------------
From: "John A.Malley" <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Mon, 02 Oct 2000 07:10:14 -0700
Francois Grieu wrote:
>
> "John A. Malley" <[EMAIL PROTECTED]> wrote:
>
> > The number e = 2^16 + 1 = 65537 is a reasonable choice for a
> > small encryption exponent (..) minimizing the threat of a
> > specific attack (from Coppersmith) that relies on the same
> > message (or a variation of that message) sent to a number of
> > different recipients. (..)
> > The attack in section 8.2.2.(ii) is from Coppersmith against
> > RSA using small encryption exponents and discussed in detail
> > in the notes for section 8.2 in section 8.8 Notes and further
> > references. See pages 313 - 314. Salting thwarts this attack.
>
> Yes, these are good reason e = 2^16 + 1 is used in encryption
> applications (though arguably with good padding/salting e = 3
> should be safe).
>
> But in a ** signature ** application there is nothing to hide,
> except how to sign, and with proper padding that resist the
> Corron-Naccache-Stern attacks [3] I see no danger with e = 3.
You are correct. There is no danger using e = 3 for verifying
signatures.
The HAC suggests using either e = 3 or e = 2^16+1 in section 11.3.3.
(iv) and (v) for fast signature verification with small exponents.
There is no reported weaknesses of RSA signature using such small
exponents.
>
> So again I wonder why e = 2^16 + 1 is increasingly prescribed.
>
Fixing the choice to e = 2^16+1 in the same code/implementation
supporting RSA encryption and RSA signatures is a reasonable
"engineering" solution.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Patrick Reynolds <[EMAIL PROTECTED]>
Subject: Project: Digital Signing and Encrypting Application
Date: Mon, 02 Oct 2000 14:11:53 GMT
Overview: Using Java, or another client side language, we wish to
build an application that utilizes Blowfish, or similar,
encryption technology to digitally sign and/or encrypt web and desktop
data.
Features: The application can be used to digitally sign MS Office
and other documents, electronically. The application can be used to
digitally sign and/or encrypt e-mail. The application can be used to
capture data entered in a web form and encrypt it before sending it to
an e-mail address.
Technology:Users can opt to create a password (or private key) which
produces a public key or alternatively they can import an RSA or
VeriSign type digital certificate and use their private/public key.
These keys whether produced by the application or by importing them,
are the basis of how the application will work.
Details: We need a total solution. In the case of the web form
application, an existing application that uses cgi scripting is
available for examination at http://securasite.com/securasite.zip with
documentation available at http://securasite.com/Tutorial.zip
In the case of the desktop component of the application an
existing application can be seen at
ftp://ftp3.elock.com/product/elock/product/etoff30.exe and
documentation is available at
ftp://ftp3.elock.com/product/elock/manual/assuredoffice/assuredofficeman
ual.pdf
NOTE: The URLs and/or programs shown are for illustrative purposes
only. We do not wish any copying, decoding, or any other such
patent/copyright infringement
Total solution and source code, ownership and title to the solution
once finished
--
Many Thanks
Patrick Reynolds
mailto:[EMAIL PROTECTED]
http://www.everyco.net
Our numbers have changed:
Telephone : +353 (1) 662-1249
Facsimile : +353 (1) 662-1652
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: CPU's aimed at cryptography
Date: Mon, 02 Oct 2000 07:20:01 -0700
My goal was to emphasize that that whereas software incarnations
of popular symmetric algorithms cannot even hope to compete against
their hardware counterparts, the same is not true of RSA.
As far as price is concerned - well, I don't know for how much
Itanium
(and later on McKinley) will sell, but with private key signature times
hovering on the millisecond mark their price/performance ratio might not
be so bad. And people with big servers and heavy traffic will want to do
this kind of operations this fast in their servers, not in a router.
Paul Rubin wrote:
> JCA <[EMAIL PROTECTED]> writes:
>
> > If we are talking 1024-bit RSA moduli, 32 ms for the signature
> > time is very unimpressive. Similar or better speeds are already
> > achieved in software on a medium range PA-RISC box, and much
> > faster performance on a 500 MHz IA64 box.
> > ...
> > > Motorola's CPU, MPC180 at:
> > > http://mot-sps.com/news_center/press_releases/PR000926A.html
> > > Analog Device's CPU, ADSP-2141 at:
> > > http://products.analog.com/products/info.asp?product=ADSP-2141L
>
> Um, it says that the MPC180 is a $20 part, and I believe the ADSP-2141
> is comparable. How much did you say an IA64 processor was? Do you
> really want to embed one in a low-end router?
------------------------------
From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: AES annoucement due Monday 2nd October
Date: Mon, 02 Oct 2000 09:55:35 -0500
On Fri, 29 Sep 2000 21:43:39 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>On 29 Sep 2000 18:54:00 GMT, [EMAIL PROTECTED] (DJohn37050) wrote, in
>part:
>
>>And they still have the option to name a multiple of algorithms.
>
>This is the *first* time they have, to my knowledge, laid claim to
>such an option.
NIST has always said that they might choose more than one AES
algorithm. They said it in Rome at the Second AES Workshop, and
possibly in California at the first. At the Third AES Workshop in NY
(this year), NIST polled the audience on the question. The response
was overwhelming for one algorithm. Thankfully, NIST listened.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Tel: 408-556-2401
3031 Tisch Way, Suite 100PE, San Jose, CA 95128 Fax: 408-556-0889
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Mon, 2 Oct 2000 17:26:05 +0200
> 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.
I've implemented erfc() in this way:
// Complementary Error Function
inline double __fastcall y(const double x) { return exp(-x*x); }
static double __fastcall erfc(const double t1,const double eps,double &ee)
{
unsigned long MOLT=20; const double x1=t1;
double a,h,s2,s4,AB=HUGE_VAL;
AREA:
double ab=HUGE_VAL,eb=HUGE_VAL;
double x2=(t1+.1)*MOLT,ys=y(x1)+y(x2);
unsigned long n=4;
simp:
h=(x2-x1)/(double)n; s2=0; s4=y(x1+h);
for(unsigned long i=2;i<=n-2;i+=2) {
s2+=y(x1+(double)i*h); s4+=y(x1+(double)(i+1)*h);
}
a=(ys+4.*s4+2.*s2)*h/3.; ee=fabs(a-ab);
if(ee>eps && ee<eb || n==4) { ab=a; eb=ee; n*=2; goto simp; }
if(ee>eb) { a=ab; ee=eb; }
if(fabs(a-AB)>eps) {
AB=a; if(t1>1e-4) MOLT+=20; else MOLT*=2;
goto AREA;
}
return M_2_SQRTPI*a;
}
I use Simpson method to calculate the integral needed for erfc(), so you
must supply:
- the x for wich you want to calculate erfc();
- the maximum absolute error (e.g. 1e-6);
- a double to store the actual error of erfc().
It return erfc() � ee.
Cristiano
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Adobe Acrobat -- How Secure?
Date: 2 Oct 2000 17:28:46 +0200
In article <8r0pc5$2nu9$[EMAIL PROTECTED]>,
David C. Barber <[EMAIL PROTECTED]> wrote:
>If
>one is to mount an attack against an Acrobat encrypted document, does it
>make more sense to: 1) Attack the reader code (as you suggested below that
>some attacks have been done, though I haven't tried any of them); 2) Attack
>the document itself with some sort of filter to remove/alter the protection
>specification value(s); or 3) Write a viewer from the specification that
>ignores the protection?
(1) is pretty easy: screen-capture software is rather widespread.
(3) is conceptually easy, just straightforward programming.
Indeed, you don't even need, that, you could just fetch an existing
pdf viewer distributed as source code, eg xpdf (http://www.foolabs.com/xpdf/)
and modify it as needed.
Note that the xpdf author specifically requests
(http://www.foolabs.com/xpdf/cracking.html) that xpdf *not* be used
in this way. But someone who wants to steal your magnum opus might
also be unethical enough to ignore the xpdf request, i.e. you shouldn't
_rely_ on that request being honored.
Conclusion:
>This does lead to an interesting question about Acrobat security though.
If you have to ask, it's not secure enough for you.
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Amount of all stock owned by the least wealthy 90% of America: 18%
Amount of all stock owned by the most wealthy 1% of America: 41%
-- Economic Policy Institute
------------------------------
From: [EMAIL PROTECTED] (David Lesher)
Subject: It's Rijndael
Date: 2 Oct 2000 11:29:07 -0400
Reply-To: [EMAIL PROTECTED] (David Lesher)
Now all the flaming can start, right?
--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 17:43:17 +0200
Yes !
See http://www.esat.kuleuven.ac.be/cosic/#press
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 17:46:09 +0300
David Lesher wrote:
> Now all the flaming can start, right?
No, why? Rijndael was objectively the favorite.
Helger
------------------------------
From: Ed Kubaitis <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 10:44:59 -0500
Quisquater wrote:
>
> Yes !
>
> See http://www.esat.kuleuven.ac.be/cosic/#press
How is it pronounced?
==========================
Ed Kubaitis ([EMAIL PROTECTED])
CCSO - University of Illinois - Urbana-Champaign
------------------------------
From: Quisquater <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 17:56:19 +0200
Ed Kubaitis wrote:
> How is it pronounced?
See http://www.esat.kuleuven.ac.be/~rijmen/rijndael/
There is a fan club page :-) http://www.rijndael.com/
------------------------------
From: [EMAIL PROTECTED] (David Lesher)
Subject: Re: It's Rijndael
Date: 2 Oct 2000 11:58:53 -0400
Reply-To: [EMAIL PROTECTED] (David Lesher)
Ed Kubaitis <[EMAIL PROTECTED]> writes:
>> See http://www.esat.kuleuven.ac.be/cosic/#press
>How is it pronounced?
First flame ;-}
--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: Ciphers and Unicode
Date: Mon, 2 Oct 2000 17:31:17 +0200
Anders Thulin <[EMAIL PROTECTED]>
>
> Worst case scenario: Encoding a 8-bit ASCII text as some form of
UTF-32 -- lots
> of 00 bytes --, and then stream coding it seems likely to produce some
detectible
> artifacts. And we have a plaintext known to 75% ...
>
Use 32bit-stream cipher.
Manuel Pancorbo
------------------------------
From: [EMAIL PROTECTED] (David Lesher)
Subject: Re: It's Rijndael
Date: 2 Oct 2000 12:01:25 -0400
Reply-To: [EMAIL PROTECTED] (David Lesher)
Helger Lipmaa <[EMAIL PROTECTED]> writes:
>> Now all the flaming can start, right?
>No, why? Rijndael was objectively the favorite.
My point exactly...
When has reason ever been needed in a flamewar?
--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Mon, 02 Oct 2000 16:04:57 +0000
Ed Kubaitis wrote:
>
> Quisquater wrote:
> >
> > Yes !
> >
> > See http://www.esat.kuleuven.ac.be/cosic/#press
>
> How is it pronounced?
It's in the FAQ on their site -- but the good news about this
choice is that you won't have to remember how it's pronounced:
it will now be pronounced Ay Ee Ess in English!
--
Jim Gillogly
Trewesday, 11 Winterfilth S.R. 2000, 16:03
12.19.7.10.15, 11 Men 18 Chen, Eighth 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
******************************
