Cryptography-Digest Digest #41, Volume #14 Fri, 30 Mar 01 08:13:01 EST
Contents:
Re: WinZip and other Zip Archivers ("Vladimir Katalov")
Re: AES - test vectors? ("Brian Gladman")
Re: Idea - (LONG) (Mok-Kong Shen)
Pseudo-random permutation generators ("Toby Sharp")
Re: Pseudo-random permutation generators (David Schwartz)
Re: Pseudo-random permutation generators ("Toby Sharp")
Support for 1536 bit RSA keys? ([EMAIL PROTECTED])
[STATS] His in-law certainly would love to fuck most of priapic NSA (lcs Mixmaster
Remailer)
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
Re: Idea - (LONG) ("Trevor L. Jackson, III")
[INFO] Green asks plenty of these mexicans (Frog2)
Re: rc4 (Phil Carmody)
Re: Support for 1536 bit RSA keys? ([EMAIL PROTECTED])
Re: Support for 1536 bit RSA keys? ("Sam Simpson")
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Lutz
Donnerhacke)
Re: Support for 1536 bit RSA keys? ("Sam Simpson")
Re: Pseudo-random permutation generators (Bob Harris)
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
Re: Support for 1536 bit RSA keys? ("Tom St Denis")
discrete log question ("Tom St Denis")
Re: Support for 1536 bit RSA keys? ("Sam Simpson")
----------------------------------------------------------------------------
From: "Vladimir Katalov" <[EMAIL PROTECTED]>
Subject: Re: WinZip and other Zip Archivers
Date: Fri, 30 Mar 2001 12:20:02 +0400
[EMAIL PROTECTED] wrote in message
<[EMAIL PROTECTED]>...
>RAR, uses it's own algorithm, not sure how strong it is..
VERY strong -- I think it is based on GOST algorithm. Known-plaintext attack
is not
possible at all; brute-force attack gives not more than just 2-3 thousand
passwords
per second. Besides, the archiver itself is EXCELLENT -- very high
compression
ratio, recovery record (for better reliability), convenient disk spanning,
creating solid
archives, support for multiple platforms etc. It becomes more and more
popular
nowadays (especially assuming that WinZip authors are paying much attacntion
to
gizmos and gadgets, but don't improve the speed and compression ratio; and
don't
like to fix bugs). I'd recommend it to everyone!
If you'd like to stay with ZIP format, look at the latest PKZip (4.0) from
PKWare, the
"father" of ZIP. It has much better user interface (than older versions),
supports AV
records and digital signatures, has new/improved compression algorithm
(deflate64)
etc. I'd say that this is absolutely the best ZIP archiver now. It allows to
do everything
you want with archives. But security hole is still there, unfortunately (no
changes in
encryption algorithm).
--
Sincerely yours,
Vladimir
Vladimir Katalov
Managing Director
Elcom Ltd.
Member of Association of Shareware Professionals (ASP)
Member of Russian Cryptology Association
mailto:[EMAIL PROTECTED]
http://www.elcomsoft.com/adc.html (Advanced Disk Catalog)
http://www.elcomsoft.com/ems.html (Email Management Software)
http://www.elcomsoft.com/prs.html (Password Recovery Software)
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES - test vectors?
Date: Fri, 30 Mar 2001 09:43:16 +0100
"Marc" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi. I'm trying to get an AES implementation to work. However, I don't
> understand the test vector format from the AES web page. The file
> "ecb_e_m.txt" begins like this this:
>
> I=0
> KEY=00000000000000000000000000000000
> PT=00000000000000000000000000000000
> CT=C34C052CC0DA8D73451AFE5F03BE297F
>
> I=1
> KEY=C34C052CC0DA8D73451AFE5F03BE297F
> PT=C34C052CC0DA8D73451AFE5F03BE297F
> CT=0AC15A9AFBB24D54AD99E987208272E2
>
> What does "I=0" mean?
>
> What is a "Monte Carlo Test"?
>
The "I=0" is just the test number.
The usual mistake that people make in running the Monte Carlo tests is that
they run the encryption or decryption operations just once.
In all these tests (but not the vt and vk ones) the encryption or decryption
operations are run 10000 times in the relevant cipher mode.
Brian Gladman
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Fri, 30 Mar 2001 11:28:36 +0200
"John A. Malley" wrote:
>
> Please see my reply to Prof. Wagner in this same thread - I elaborated
> what I was searching for with respect to block ciphers and perfect
> secrecy.
>
> I hope it clarifies my question.
The format makes it uncertain whether the above is responding
to my follow-up, but I suspect that it could be.
I don't yet understand. My point was that, if you change
you four variable length messages to constant length ones,
as I indicated in my follow-up, then the encryption
becomes a normal block encryption (the characteristic
of a block encryption is that it transforms a constant
number of bits to the same number of bits, in the present
case 2). So with that change you obtain a block cipher.
All the computations about probabilities remains the same.
In other words, your statements relating to Shannon
and his perfect security in the case of your original
example translates to the modified example unchanged.
Doesn't that achieves your goal of finding a block
cipher under the said context of Shannon? Thanks.
M. K. Shen
------------------------------
From: "Toby Sharp" <[EMAIL PROTECTED]>
Subject: Pseudo-random permutation generators
Date: Fri, 30 Mar 2001 11:32:59 +0100
Can anyone explain how to construct a pseudo-random permutation generator,
perhaps from a pseudo-random sequence generator? Speed is the foremost
issue; the output will not be available to an attacker, so does not need to
be cryptographically secure in the sense of cracking it from fragmented
output.
Thanks,
Toby.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Pseudo-random permutation generators
Date: Fri, 30 Mar 2001 02:44:48 -0800
Toby Sharp wrote:
> Can anyone explain how to construct a pseudo-random permutation generator,
> perhaps from a pseudo-random sequence generator? Speed is the foremost
> issue; the output will not be available to an attacker, so does not need to
> be cryptographically secure in the sense of cracking it from fragmented
> output.
One easy way is to round the number of objects up to the nearest power
of two. Then construct a block cipher with a block size of that number
of bits. Then encrypt, using a random key, the numbers zero through the
maximum. Discard all output above the maximum desired value.
So if you have 212 objects you want to permute (0 through 211), you
make a block cipher with an 8-bit block. You then encrypt the numbers
zero through 256 sequentially. Discard all values above 211.
DS
------------------------------
From: "Toby Sharp" <[EMAIL PROTECTED]>
Subject: Re: Pseudo-random permutation generators
Date: Fri, 30 Mar 2001 12:08:03 +0100
Thanks. I haven't studied crypto methods, but I'll read up on block ciphers.
Toby.
David Schwartz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Toby Sharp wrote:
>
> > Can anyone explain how to construct a pseudo-random permutation
generator,
> > perhaps from a pseudo-random sequence generator? Speed is the foremost
> > issue; the output will not be available to an attacker, so does not need
to
> > be cryptographically secure in the sense of cracking it from fragmented
> > output.
>
> One easy way is to round the number of objects up to the nearest power
> of two. Then construct a block cipher with a block size of that number
> of bits. Then encrypt, using a random key, the numbers zero through the
> maximum. Discard all output above the maximum desired value.
>
> So if you have 212 objects you want to permute (0 through 211), you
> make a block cipher with an 8-bit block. You then encrypt the numbers
> zero through 256 sequentially. Discard all values above 211.
>
> DS
------------------------------
From: [EMAIL PROTECTED]
Subject: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 11:38:21 GMT
Thanks for reading this.
I am trying to assess cryptographic toolkit, certificate generation software,
certificate validation software vendor support for 1536-bit RSA keys.
I expect good support for 1024-bit and 2048-bit keys as they are "standard" key
lengths. Should I expect such good support for 1536-bit keys?
Any idea of how I could find evidence of vendor support for such key lengths? I
have checked a number of vendor web sites but I haven't really found any
relevant information.
Thanks a lot in advance for any help.
texica
------------------------------
Date: 30 Mar 2001 12:00:04 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: [STATS] His in-law certainly would love to fuck most of priapic NSA
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
CIA needs republicans
Mix sure loves NSA
Randseed requires to fist-fuck obnoxious democrats
Tuttle would love to fuck FBI
0,7278311 0,2536827 5,741435E-02 -2001/03/25 17:22:24-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
Cracow probably needs these onions
My sister requires tasty toilet paper
Green would love to decypher nice VB code
Uppnorth used those C++ code
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 12:01:21 GMT
<[EMAIL PROTECTED]> wrote in message
news:Ne_w6.1530$[EMAIL PROTECTED]...
> Thanks for reading this.
>
> I am trying to assess cryptographic toolkit, certificate generation
software,
> certificate validation software vendor support for 1536-bit RSA keys.
>
> I expect good support for 1024-bit and 2048-bit keys as they are
"standard" key
> lengths. Should I expect such good support for 1536-bit keys?
This is because you're a nutcase. Factoring is a hard job. "2048-bit keys"
are not standard ... they are for paranoids.
> Any idea of how I could find evidence of vendor support for such key
lengths? I
> have checked a number of vendor web sites but I haven't really found any
> relevant information.
Any good kit should be able to make any size RSA key... it's not terribly
hard just make two n/2 bit primes..
Tom
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Fri, 30 Mar 2001 12:07:10 GMT
"John A. Malley" wrote:
> David Wagner wrote:
> >
> > John A. Malley wrote:
> > >We tend to forget that perfect secrecy without an OTP is possible for a
> > >finite number of messages as illustrated by the example provided in the
> > >post.
> >
> > Obviously it's possible to do this without an OTP, but as far as I
> > can tell, the resulting systems are no more practical than a OTP is,
> > so what's the point?
>
> I was thinking about a proof for or against the existence of a block
> cipher algorithm exhibiting perfect secrecy.
>
> Such a block cipher algorithm
>
> 1) takes an n-bit block of plaintext,
> 2) takes an n-bit key chosen uniformly at random from the set of 2^n
> possible keys,
>
> and
>
> 3) maps each n-bit plaintext string p_i to each n-bit ciphertext string
> c_j by exactly one key k_l out of the 2^n keys.
It appears to me that there are 2^n keys, but (2^n)! possible maps. So for
n>1 there's an implicit imperfection in that the perfect secrecy applies only
at the block level rather than the message level.
Perhaps there's an approach that describes this lack at the binary operator
level like Galois' proof of the intractability of quintics.
------------------------------
From: Frog2 <[EMAIL PROTECTED]>
Date: 30 Mar 2001 12:28:38 -0000
Subject: [INFO] Green asks plenty of these mexicans
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
The dog used priapic democrats
Licious fucking wants to eat politically correct FBI
Tr: His cat used remaining of tasteful NSA
My brother probably needs to read plenty of those NSA
0,910373 0,1963524 0,8210191 -2001/03/25 17:06:23-
Script-Kiddie MASTER of APAS/ADRU/SM/AUK
For a 21st Century completely REMAILER-FREE
That CRAP brought to you by request from Thomas J. BOSCHLOO
[EMAIL PROTECTED]
The bishop sure needs to burn all some priapic faggots
Lcs asks more of tasteful MIX keys
Arafat used to fuck those spotty jews
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: rc4
Date: Fri, 30 Mar 2001 12:30:39 GMT
>
> Nope, you didn't miss anything. There's actually a bug in the
> "compacted version" that you're using (rc4-2). The bug is in the loop
> that looks like this:
>
> c=256;while(p[c]=--c);
>
> Depending on the C compiler, this can legitimately be compiled to do
> two quite different things: the c index on the left is either the
> original value or the incremented value of c. Apparently
> the person who wrote (and presumably tested) this code had a compiler
> that did it one way (using the incremented version of c), and your
> compiler does it the other way, leading to incompatibilities.
It's called "undefined behaviour" and it is a "bad thing".
Very well spotted though. (It is statically detectable by the compiler,
so I think compilers should detect and warn about these things.)
> Here's a version that works, by replacing that loop:
#define W(X) 256;h=*(p+X);*(p+X)=*(p+j);*(p+j)=h;/* Use: rc4 hexkey <in
>out */
unsigned char s[256],d[512],b[8192],i,j,p[256];int h,n,m;main(int c,char
*v[]){
while((m=read(0,b,8192))>0){if(c>1){(n=strlen(strcpy(d,v[1])))&1&&n++&&strcat(d
,"0");n/=2;for(c=0;c<n;c++){*p=d[c*2];p[1]=d[c*2+1];sscanf(p,"%x",&h);s[c]=h;}c
=255;for(;p[c]=c;--c);do{j=(s[i]+p[c]+j)%W(c)i=(i+1)%n;}while(256-++c);for(c=i=j
=0;c<m;c++){j=(p[i=(i+1)%256]+j)%W(i)b[c]^=p[(p[i]+p[j])%256];}}write(1,b,m);}}
(I hate to see code quoted and indented and stuff, that's verbatim)
> That kills the cute property that each line is exactly 79 characters
> long, but I wanted to make it correct, not "cute".
A character is saveable by
c
=255;for(;p[c]=c;--c);
becoming
for(c=255;p[c]=c;--c);
But it doesn't save the jagged edge.
However, are the following the same?
do{j=(s[i]+p[c]+j)%W(c)i=(i+1)%n;}while(256-++c);
for(--c;256-++c;)j=(s[i]+p[c]+j)%W(c)i=(i+1)%n;
which saves 2 characters.
The 'one character too short' property of the 4th and 5th line can be
countered with a simple trailing backslash!
There ain't no such thing as the shortest code...
Phil Carmody
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 12:30:48 GMT
Tom
>This is because you're a nutcase. Factoring is a hard job. "2048-bit keys"
>are not standard ... they are for paranoids.
Thanks :-)
We are talking about keys used in extremely secure environments and with very
long lifetimes (20+ years)...
Anyway, my question was not whether it is reasonable or not, but whether vendors
support it.
>Any good kit should be able to make any size RSA key... it's not terribly
>hard just make two n/2 bit primes..
I know that. Thanks.
texica
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 13:34:13 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:lA_w6.163933$[EMAIL PROTECTED]...
>
> <[EMAIL PROTECTED]> wrote in message
> news:Ne_w6.1530$[EMAIL PROTECTED]...
> > Thanks for reading this.
> >
> > I am trying to assess cryptographic toolkit, certificate generation
> software,
> > certificate validation software vendor support for 1536-bit RSA keys.
> >
> > I expect good support for 1024-bit and 2048-bit keys as they are
> "standard" key
> > lengths. Should I expect such good support for 1536-bit keys?
>
> This is because you're a nutcase. Factoring is a hard job. "2048-bit
keys"
> are not standard ... they are for paranoids.
"If 512-bit keys are insecure today, they were just as insecure last month.
Anyone implementing RSA should have moved to 1028-bit keys years ago, and
should be thinking about 2048-bit keys today. It's tiring when people don't
listen to cryptographers when they say that something is insecure, waiting
instead for someone to actually demonstrate the insecurity.".
-- Schneier, Cryptogram, 15/9/99
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: 30 Mar 2001 12:36:45 GMT
* Rich Wales wrote:
>2.6.3ia would appear to be vulnerable to the ICZ attack. At the very
>least, I would assume that a validity test on "pInv" must be added in
>order to protect against the attack.
This would solve excatly the situation described in the paper. My patch
solves two additional attacks.
>BTW, the fact that the real "p" and "q" must be used is why the attack
>requires the victim to be tricked into signing something using the
>doctored secret key -- something that can only be done by someone who
>knows the pass phrase (i.e., the victim).
Wrong. It is more complex but still possible to mount a similar attack to
system computing y^d % n directly.
>Validity tests on "p" and/or "q" are probably superfluous from the
>standpoint of the ICZ attack -- since a mangled "p" or "q" will cause the
>attack to fail anyway -- but I suppose it isn't a bad idea to check "p"
>and "q" anyway, just in case some similar attack exists that could exploit
>such a change.
Please do read the Bellcore paper about DFA. The Czech attack realizes a
very special case of a general cryptonalysis. You may check whatever you
want before calculation and reveal the private key anyway.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 13:44:47 +0100
<[EMAIL PROTECTED]> wrote in message
news:Y%_w6.1543$[EMAIL PROTECTED]...
> Tom
>
> >This is because you're a nutcase. Factoring is a hard job. "2048-bit
keys"
> >are not standard ... they are for paranoids.
>
> Thanks :-)
> We are talking about keys used in extremely secure environments and with
very
> long lifetimes (20+ years)...
For long term data, I'm with you: 2048 as a *minimum*.
Have a look at the paper "Discrete logarithms: The past and future" by
A.M.Odlyzko July 1999, to quote:
"...keys have to be at least 1024 bit even for moderate security, and a
least 2048 for anything that should remain secure for a decade...".
> Anyway, my question was not whether it is reasonable or not, but whether
vendors
> support it.
Some do, sure. Have a look at the Crypto++ 4.1 lib by Wei Dai:
http://www.eskimo.com/~weidai/cryptlib.html
or Cryptlib by Peter Gutmann http://www.cs.auckland.ac.nz/~pgut001/cryptlib/
IIRC, both of these free libraries support the keysizes you require.
For 'pay' libraries, I haven't got a clue......................
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Subject: Re: Pseudo-random permutation generators
Date: Fri, 30 Mar 2001 07:48:59 -0500
Toby Sharp wrote:
> Can anyone explain how to construct a pseudo-random permutation generator,
> perhaps from a pseudo-random sequence generator? Speed is the foremost issue;
> the output will not be available to an attacker, so does not need to be
> cryptographically secure in the sense of cracking it from fragmented output.
Depending on your needs, you may do this in other ways, too. Take a look at
the thread "Newbie wants to shuffle..." which started in this newsgroup
Mar/27.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 12:53:59 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:J0%w6.2868$[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:lA_w6.163933$[EMAIL PROTECTED]...
> >
> > <[EMAIL PROTECTED]> wrote in message
> > news:Ne_w6.1530$[EMAIL PROTECTED]...
> > > Thanks for reading this.
> > >
> > > I am trying to assess cryptographic toolkit, certificate generation
> > software,
> > > certificate validation software vendor support for 1536-bit RSA keys.
> > >
> > > I expect good support for 1024-bit and 2048-bit keys as they are
> > "standard" key
> > > lengths. Should I expect such good support for 1536-bit keys?
> >
> > This is because you're a nutcase. Factoring is a hard job. "2048-bit
> keys"
> > are not standard ... they are for paranoids.
>
> "If 512-bit keys are insecure today, they were just as insecure last
month.
> Anyone implementing RSA should have moved to 1028-bit keys years ago, and
> should be thinking about 2048-bit keys today. It's tiring when people
don't
> listen to cryptographers when they say that something is insecure, waiting
> instead for someone to actually demonstrate the insecurity.".
So let's use 10kbit rsa keys?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 12:55:16 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:Ba%w6.2882$[EMAIL PROTECTED]...
> <[EMAIL PROTECTED]> wrote in message
> news:Y%_w6.1543$[EMAIL PROTECTED]...
> > Tom
> >
> > >This is because you're a nutcase. Factoring is a hard job. "2048-bit
> keys"
> > >are not standard ... they are for paranoids.
> >
> > Thanks :-)
> > We are talking about keys used in extremely secure environments and with
> very
> > long lifetimes (20+ years)...
>
> For long term data, I'm with you: 2048 as a *minimum*.
>
> Have a look at the paper "Discrete logarithms: The past and future" by
> A.M.Odlyzko July 1999, to quote:
> "...keys have to be at least 1024 bit even for moderate security, and a
> least 2048 for anything that should remain secure for a decade...".
This is contrary to the notion of "making predictions is foolish". If we
manage to factor 1024 bit numbers I think 2048 will fall too since it will
require some sort of "unimaginable" computer to factor 1024-bit rsa
numbers...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: discrete log question
Date: Fri, 30 Mar 2001 13:03:55 GMT
(Wow I am really on a question rampant now...)
To solve a trivial discrete log (say p = 11 = 2x5 +1) is it sufficient to
use crt? i.e
Given g=7, x=3, y=g^x mod p = 2
Can we not compute
g^x mod 5 = y' = 2
g^x mod 2 = y'' = 1
Then solve the discrete log mod 5 and mod 2 using trial and error getting us
(x mod 4) and (x mod 1)?
... hmm somethings missing... am I approaching this right?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Support for 1536 bit RSA keys?
Date: Fri, 30 Mar 2001 14:03:34 +0100
Why not? If you can stomach the speed issues (e.g. key is a key signing CA
key used v. occasionally) and you can gather the entropy to produce such a
large key...
I'm sure people said the same kind of thing about 1500-bit keys when 512 was
the de facto standard..........
--
Regards,
Sam
http://www.scramdisk.clara.net/
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:Hl%w6.163951$[EMAIL PROTECTED]...
>
> "Sam Simpson" <[EMAIL PROTECTED]> wrote in message
> news:J0%w6.2868$[EMAIL PROTECTED]...
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:lA_w6.163933$[EMAIL PROTECTED]...
> > >
> > > <[EMAIL PROTECTED]> wrote in message
> > > news:Ne_w6.1530$[EMAIL PROTECTED]...
> > > > Thanks for reading this.
> > > >
> > > > I am trying to assess cryptographic toolkit, certificate generation
> > > software,
> > > > certificate validation software vendor support for 1536-bit RSA
keys.
> > > >
> > > > I expect good support for 1024-bit and 2048-bit keys as they are
> > > "standard" key
> > > > lengths. Should I expect such good support for 1536-bit keys?
> > >
> > > This is because you're a nutcase. Factoring is a hard job. "2048-bit
> > keys"
> > > are not standard ... they are for paranoids.
> >
> > "If 512-bit keys are insecure today, they were just as insecure last
> month.
> > Anyone implementing RSA should have moved to 1028-bit keys years ago,
and
> > should be thinking about 2048-bit keys today. It's tiring when people
> don't
> > listen to cryptographers when they say that something is insecure,
waiting
> > instead for someone to actually demonstrate the insecurity.".
>
> So let's use 10kbit rsa keys?
>
> Tom
>
>
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
