Cryptography-Digest Digest #34, Volume #14 Thu, 29 Mar 01 04:13:01 EST
Contents:
WinZip and other Zip Archivers ("Moritz Voss")
Re: Deny Anon Remailers access to this newsgroup (Darren New)
Re: Malicious Javascript in Brent Kohler post (Darren New)
Re: WinZip and other Zip Archivers ([EMAIL PROTECTED])
Re: Idea - (LONG) ("John A. Malley")
Re: Data dependent arcfour via sbox feedback (Lassi =?iso-8859-1?Q?Hippel=E4inen?=)
Re: texts on factoring? (Stefan Katzenbeisser)
Clarification about the Czech attack to PGP (Lutz Donnerhacke)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Lutz
Donnerhacke)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Imad R.
Faiad)
Re: texts on factoring? (Paul Rubin)
Re: WinZip and other Zip Archivers (Paul Rubin)
Re: DES key replacement. (Frank Gerlach)
Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
([EMAIL PROTECTED])
Re: Estimation of the keygen time (Bob Deblier)
Re: Breaking a DES encrypted code. (Mok-Kong Shen)
Re: WinZip and other Zip Archivers ("Moritz Voss")
Re: Malicious Javascript in Brent Kohler post (Mok-Kong Shen)
Re: Clarification about the Czech attack to PGP (Volker Hetzer)
----------------------------------------------------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: WinZip and other Zip Archivers
Date: Thu, 29 Mar 2001 08:33:49 +0200
These have a password function, as people might know.
Is the encryption anything close to "secure" or is this just some 'cheap',
'keep dummies out ofr a while' algorithm like just xoring a few plaintext
characters...
--
--
Moritz "Thygrrr" Voss
Client-Server & OpenGL Developer
http://www.optionoverkill.com
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Deny Anon Remailers access to this newsgroup
Date: Thu, 29 Mar 2001 06:40:21 GMT
David A Molnar wrote:
> I suspect that might have been a reference to anon.penet.fi . Then again, I
> might just be reading things which aren't there (I do this in class often
> enough).
I didn't mean to offend anyone who likes Finland. There's someone who wears
a tinfoil-hat and posts the most absurd messages to sci.crypt about how
he's being persecuted and all. My favorite was his ex-blood relatives (think
about it) trying to deport him to Finland for some reason after having the
FBI steal all the money out of his bank accounts. Or something like that.
If you don't recognise the reference, it's not funny. But it wasn't a cut at
anyone's homeland or anything.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
A million monkeys in a room with a million typewriters
will only yield half a million pregnant monkeys.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Malicious Javascript in Brent Kohler post
Date: Thu, 29 Mar 2001 06:43:12 GMT
> Thanks. If that's the worst thing to be expected from
> any javascript, then I wouldn't care.
It's not. That just happens to be what this piece did. And every Javascript
implementation is different, so what they can do varies. You probably don't
even want your email address being posted up on a web site by the
javascript.
> Allow me another
> question of ignorance: What about stuffs that contains
> ActiveX? (I have no knowledge of ActiveX at all.)
As far as I understand it, an ActiveX thingie is a raw executable running
with your permissions when you run it. The only protection is that it's
signed. But it's quite capable in general of deleting all your files after
uploading them to someone else, installing new software, etc.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
A million monkeys in a room with a million typewriters
will only yield half a million pregnant monkeys.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: WinZip and other Zip Archivers
Date: Thu, 29 Mar 2001 06:49:56 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Moritz Voss wrote:
> Is the encryption anything close to "secure" or is this just some 'cheap',
> 'keep dummies out ofr a while' algorithm like just xoring a few plaintext
> characters...
Zip encryption is week (although it's better than just xoring)
there is known plaintext attack that requires only known 13 bytes
and then it can be broken in few hours
but there are some other archivers that use better crypto
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
^--GPG for Win32 (supports loadable modules and IDEA)
^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOsK+8jBaTVEuJQxkEQL6dACg2rt465Kabkvqq2D90g/U3LWsHsoAnAii
4cYQwYNCTTnwV1ZxEJPqpMl7
=xOBY
=====END PGP SIGNATURE=====
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Wed, 28 Mar 2001 23:06:05 -0800
"SCOTT19U.ZIP_GUY" wrote:
> So at the very least try to get Shannon
> correct. In his defination of "Perfect encryption" where an enemy
> gains no more knowledge about a possible message than he knew before
> it was sent. The key should have at least as many possible values as
> the number of possible messages.
Shannon called this "perfect secrecy", achieved with the number of keys
equal to the number of messages. For perfect secrecy, the probability
that the plaintext = X given the ciphertext = Y is the same as the
probability that the plaintext = X.
Exactly as you said, the enemy gains no knowledge from the ciphertext
intercepts.
> In what Shannon refers to as an "ideal system" He goes on to state
> that it is possible to construct encryption system where one only
> has a finite number of keys. So that even with infinite amount of
> cipher text. There still is not enough INFORMATION in the cipher
> text to know what the solution is.
According to Shannon's paper, in an ideal system the number of
cryptograms, the number of messages and the number of keys are all
equal (and finite.) Each key is equiprobable. No two keys ever map the
same message to the same cryptogram - or stated another way, each
message m_i is
mapped to each cryptogram c_i by exactly one key.
The amount of information in a message is at most log(n) where n is the
number of possible messages. This information can be concealed
completely only if the key uncertainty
is at least log(n).
Mr Scott is right, the key length does not need to be
the same as the message length - the uncertainty of the key must be
equal or greater than the uncertainty of the messages.
Here's an interesting example of a perfect system per Shannon's
definition where the key length in bits is shorter than some of the bit
lengths of messages, and the perfect system is not an OTP:
There are four messages in the set M = { m1, m2, m3 , m4 } and P(m1) =
1/2, P(m2) = 1/4, P(m3) = P(m4) = 1/8 where P(m_i) means probability of
occurrence of m_i.
The uncertainty of M, H(M), is
H(M) = - ( - 1/2 * 1 - 1/4 * 2 - 1/8 * 3 - 1/8 *3 ) = 1.75 bits.
Encode the messages as these bit strings
m1 = 0
m2 = 10
m3 = 110
m4 = 111
Perfect secrecy requires the uncertainty of the key be equal to or
greater than the uncertainty of the messages - so we need a key 1.75
bits or longer. Each key value must be equiprobable. That points to a
2 bit key to encrypt this set of messages with perfect secrecy:
k1 = 00 selects this mapping:
m1 = 0 <-> c1 = 0
m2 = 10 <-> c2 = 10
m3 = 110 <-> c3 = 110
m4 = 111 <-> c4 = 111
k2 = 01 selects this mapping:
m1 = 0 <-> c1 = 10
m2 = 10 <-> c2 = 110
m3 = 110 <-> c3 = 111
m4 = 111 <-> c4 = 0
k3 = 10 selects this mapping:
m1 = 0 <-> c1 = 110
m2 = 10 <-> c2 = 111
m3 = 110 <-> c3 = 0
m4 = 111 <-> c4 = 10
k4 = 11 selects this mapping:
m1 = 0 <-> c1 = 111
m2 = 10 <-> c2 = 0
m3 = 110 <-> c3 = 10
m4 = 111 <-> c4 = 110
Alice and Bob chose a secret key (00, 01, 10 or 11) and exchange it only
between themselves.
Alice and Bob send messages m1, m2, m3 and m4 to one another as
ciphertext c1, c2, c3 and c4. They decode them according to the
appropriate mapping as a function of the secret key value.
Eve knows Alice and Bob exchange messages in the set M and she knows
their relative frequencies (or a priori probabilities.) Eve intercepts
ciphertexts c_i. What more can she learn about which messages m_i were
sent given that intercepted ciphertext? Can she figure out if its more
probable particular m_i was sent given she sees a particular c_j?
The conditional probability that the m_i message was sent given the c_j
ciphertext is seen is
P( m_i | c_j ) = P( m_i ) * P( c_j | m_i ) / P( c_j ) = P( m_i ) when
there is perfect secrecy.
Let's calculate the probability the message is m1 given we see the
ciphertext 10.
The probability of seeing 10 in the ciphertext is
P( k = 00 )*P( m2) + P( k = 01)*P(m1) + P( k = 10 )*P(m4) + P( k =
11)*P(m3) =
1/4 * 1/4 + 1/4 * 1/2 + 1/4 * 1/8 + 1/4 * 1/8 = 1/4.
The probability of ciphertext 10 given message m1 is the probability of
key k2 = 1/4.
The probability of message m1 is 1/2.
So P( m1 | 10 ) = ( 1/2 * 1/4 ) / 1/4 = 1/2 = P( m1).
When Eve sees 01 she knows it has a 50% chance of corresponding to the
plaintext message 0, 25% chance of corresponding to 10, 12.5% chance of
corresponding to 110 and 12.5% chance of corresponding to 111. In fact,
no matter what cryptograms she sees (00, 01, 10, 11) she only knows that
each intercepted ciphertext has a 50% chance of corresponding to the
plaintext message 0, 25% chance of corresponding to 10, 12.5% chance of
corresponding to 110 and 12.5% chance of corresponding to 111.
The ciphertext tells Eve nothing more than what she already knows - the
relative frequencies of m1, m2, m3 and m4.
This holds for other specific messages and specific cryptograms as well
:
P( m_i | c_j ) = P( m_i ) for all i, j for this example cipher.
This cipher gives perfect secrecy with a 2 bit key even when some of the
plaintext is 3 bits long and some of the plaintext is just 1 bit long.
This perfect system is not an OTP. The mappings 00, 01, 10 and 11 are
permutations on the message set M.
Later in his paper, Shannon addresses infinite sources:
"The situation is somewhat more complicated if the number of messages is
infinite. Suppose, for example, that they are generated as infinite
sequences of letters by a suitable Markov process. It is clear that no
finite key will give perfect secrecy. We suppose, then, that the key
source generates key in the same manner, that is, an infinite sequence
of symbols. Suppose further that only a certain length of key L_k is
needed to encipher and decipher a length L_m of message. Let the
logarithm of the number of letters in the message alphabet be R_m and
that for the key alphabet K_k. Then, for the finite case, it is evident
that perfect secrecy requires
R_m * L_m <= R_k * L_k .
This type of perfect secrecy is realized by the Vernam system."
- "Communications Theory of Secrecy Systems", Bell Systems Technical
Journal, 1949, pp. 682.
This is the ultimate source of the popular rule of thumb that the "key
must be as long as the message."
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Lassi =?iso-8859-1?Q?Hippel=E4inen?= <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Thu, 29 Mar 2001 07:08:58 GMT
"Henrick Hellstr�m" wrote:
>
> "Terry Ritter" <[EMAIL PROTECTED]> skrev i meddelandet
<...>
> [snip]
> > >Could you please tell me in what European country IDEA is patented?
> Monaco?
> > >Liechtenstein? Andorra? Malta? ;-)
I think there is a listing in the Ascom web site. That is their view in
the matter.
> > It's not my patent, but it is well known in cryptography. Are you
> > unfamiliar with the concept of a European Patent Office?
>
> No, I'm not unfamiliar with the existence of EPO. EPO usually does not issue
> any patents of their own. Mostly they only assist you when filing
> applications to the patent officies in the member states, etc. However, the
> member states may delegate the authority to issue certain types of patents
> to EPO (which I don't know if they actually have done or only intend to do
> as part of the EU integration process), so the situation is quite complex.
Please remember that the EPO is NOT the Patent Office of the EU. Both
have common member countries, but both also have members that are not
members in the other one. They are independent international
organisations with different charters.
EPO helps in getting international PCT patents. They may be different in
each country. It also issues "Europatents" that are the same in the
member countries listed in the patent.
-- Lassi
> --
> Henrick Hellstr�m [EMAIL PROTECTED]
> StreamSec HB http://www.streamsec.com
------------------------------
Date: Thu, 29 Mar 2001 09:40:31 +0200
From: Stefan Katzenbeisser <[EMAIL PROTECTED]>
Subject: Re: texts on factoring?
Tom St Denis wrote:
> I have read a few papers on the NFS alot of it is not complete... i.e they
> use sentences and say "See [14] for more". I will pick up Koblitz book
> tommorow (well I will order it then) and read up...
You might also try to read
ftp://ftp.informatik.th-darmstadt.de/pub/TI/lecture_notes/factoring.ps.gz
The text is really a good introduction to the field. The first 2.5 sections
should be readable with only a basic understanding of number theory...
Another source is Riesel's book on factorization methods:
Hans Riesel, "Prime Numbers and Computer Methods for Factorization",
Birkhaeuser, 1994.
I suggest to start reading appendices 1-3 (which give a basic introduction
to algebra and number theory) and then continue with chapters 5 and 6;
if you are only interested in factoization methods, you may safely skip
the chapters 1-4 ;-)
--Stefan.
------------------------------
From: [EMAIL PROTECTED] (Lutz Donnerhacke)
Crossposted-To:
de.comp.security.misc,alt.privacy.anon-server,alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.resources,comp.security.pgp.tech
Subject: Clarification about the Czech attack to PGP
Date: 29 Mar 2001 07:54:02 GMT
* Tomas Rosa wrote:
>Good encryption (as the method for preserving data confidentiality) shall
>be resistant to known "sound" cryptanalysing techniques. So, it has to be
>resistant to sound tampering techniques too. So, the encryption of private
>key in OpenPGP is not good.
As said last week: Good work.
But I'd like to clarify some things, because you constantly spead some FUD.
Your attack vanishs non of the following item: Key managment, Encryption,
Signatures, Certificates, Credibility or even the OpenPGP format. You
attack a design principle which can be fixed without modifications of the
format.
PGP was created on a set of principles:
1 Run on a single user, single tasking OS without networking capabilities.
2 Data written to the local storage can be securely read back.
3 Data on the local storage may be robbed.
4 Data in transport may read, modified and deleted by an attacker.
So the data format was choosen to prevent a reading attacker from easily get
the private key data. The critical parts are crypted.
Your contribution to the comunity is to do a reality check. Unfortunly
involved people tend to be unable to realize.
By brushing up the first priciple to "Run on a not self administrated, multi
user, multi tasking OS with permanent network connection" in connection with
the well known worm attacks against such enviroments you be able to kick
away the second priciple. Thanks for this.
Testing your approach you noticed, that several implementations relay on the
second priciple and fail to check the validity of the local stored data.
That's an important security flaw! Thanks for this.
As you may also noticed, the patches against your attack and two other
unrelated attacks came out a few hours after publishing your Czech paper. To
be honest, your press release was sufficient to deduced the attack, so I had
a night to sleep about the patch. The few hours delay are due to my limited
knowledge of DSA, so I had to brush up my theoretical background before
publishing the patch. Other implementors had mor problems on deducing the
correct attack and failed to create a vaid patch unless your English paper
was published.
Looking back, I have to say, that you overvalue your attack by ignoring a
much more horrible scenario which reveals the private key without any
modification to the user data. (Use braindead overclocking to mount a
probable Bellcore attack.) You did not understand you own attack: You did
not attack the certifcates, the encryption or the key management. You
attacked a design principle and mount a attack to a choosen user key (for a
user ignoring the PGP documentation about secret key storage). So your
attack is not able to attack a CA key or any important key in the web of
trust.
Of course the OpenPGP format does not say anything about local storage, so
implementors are urged to brush up the storage modul. OpenPGP says something
about the transfer of (key) data. It does not claim internal integrity
mailed private keys, but provides a format how to export a secret key, sign
it and encrypt it for transport. Your attack can only be mounted against
mailed unencrypted unsigned secret keys. But this is a very uncommon scenario.
So please calm down.
------------------------------
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: 29 Mar 2001 07:54:52 GMT
* Rich Wales wrote:
>Regarding older PGP's and this attack, PGP 2.6.3ia performs one (and
>apparently only one) of the RSA tests recommended in the ICZ paper
>(n=pq is verified in keymgmt.c, line 626).
>
>I'm not sure whether this single test suffices to make PGP 2.6.3ia
>immune to the ICZ attack or not.
It does not.
>Lutz Donnerhacke's latest 2.6.3in release includes additional tests
>(in rsaglue1.c and rsaglue2.c), which are intended to confirm the
>validity of the secret key, and thus guard against the ICZ attack.
Yep.
------------------------------
From: Imad R. Faiad <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged
Date: Thu, 29 Mar 2001 11:10:00 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hello Tom,
I can confirm that validation tests are performed
for RSA private keys prior to using them in PGP
5.0, 5.5.3, 6.0.2, 6.5.1, and 6.5.8.
Hope the above helps.
Best Regards
Imad R. Faiad
On Thu, 29 Mar 2001 00:31:14 GMT, in alt.security.pgp Tom McCune
<[EMAIL PROTECTED]> wrote:
>Newsgroups: alt.security.pgp,sci.crypt,comp.security.pgp.discuss
>Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to
>be Forged From: Tom McCune <[EMAIL PROTECTED]>
>Date: Thu, 29 Mar 2001 00:31:14 GMT
>
>
>*** PGP Signature Status: unknown
>*** Signer: Unknown
>*** Signer Key ID:0x0DA37DA1980C2DF9
>*** Signed: 3/29/2001 4:33:15 AM
>*** Verified: 3/29/2001 10:58:24 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>
>In article <[EMAIL PROTECTED]>, Imad R. Faiad
><[EMAIL PROTECTED]> wrote:
>
>>Hello Tom,
>>
>>The reason that such attacks will fail when
>>aimed at PGP RSA keys, at least in PGP 6.5.1,
>>and PGP 6.5.8, and PGP 7.x.x (if the code has
>>not changed), is because of the extra code to validate
>>all key parameters before using the private key.
><snip>
>
>Thanks Imad - I appreciate the assistance. I hope someone will be able
>to advise as to whether earlier PGP versions will fail such an attack on
>RSA keys.
>
>
>*** END PGP VERIFIED MESSAGE ***
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xBCC31718833F1BAD
Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45
iQEVAwUBOsLfb7zDFxiDPxutAQFhxgf+Ou3WVvDNVj7xm6bdo2HhocjudlIxYwaL
PG97jVSRsEPMKzBesbag8WROAOynDyi9bJnhLyT1HiIx2cRNn5410ipbqlQd0S4R
Xw9MZthhPhOn38vMgarq9X4ud3cbtfH/I4mnRILZMSVFGxfZSuuxTnSCDxnmAoVX
FXy1cAxoaXh/mcG8fG9wvRJBp+Q++TKBsIcO5G+OGKF2FLvDKIoFTwfQbTXs5TIp
wa/sYq98JVbC/3zyt2IHeKcupoIjVynI1GP38UNwnOVdYXayw+fdbFcmtw+QmOBx
kvHubmiBq/wBWKF87IC588BKy4K1XQh4W+4K18JBgluuwTJKQ93JHg==
=nC+H
=====END PGP SIGNATURE=====
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: texts on factoring?
Date: 29 Mar 2001 00:15:02 -0800
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> I have read a few papers on the NFS alot of it is not complete... i.e they
> use sentences and say "See [14] for more". I will pick up Koblitz book
> tommorow (well I will order it then) and read up...
Tom, there are a bunch of articles in various places that explain the
NFS in general terms. That's nice for some purposes but I'm assuming
you want to actually understand the algorithms to the level of being
able to implement them from knowledge of how they work (rather than
typing in formulas). I think the NFS is far too complicated to
understand at your current math level. The more elementary methods
including the ECM are probably within reach.
As for algebra books, I've seen Artin's and liked it; Fraleigh's is
widely used but I'm not so crazy about it. I used van der Waerden's
which is a classic, but I think considered fuddy duddy by today's
standards. Herstein has a new one that looks good--his earlier
"Topics in Algebra" is wonderful, but maybe a little hard to get
started with. It's often helpful to get several books and flip
between them when the explanation of a topic is confusing.
Finally I like the book "Concrete Mathematics" by Knuth, Graham, and
Patashnik, though it's not an algebra book. It's mostly the same math
you get by osmosis from Knuth TAOCP vol 1, but presented in a slower
paced and more organized way.
You're probably at the point where you should be taking university
math classes. Can your high school set you up with something like
that?
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: WinZip and other Zip Archivers
Date: 29 Mar 2001 00:18:41 -0800
"Moritz Voss" <[EMAIL PROTECTED]> writes:
> These have a password function, as people might know.
>
> Is the encryption anything close to "secure" or is this just some 'cheap',
> 'keep dummies out ofr a while' algorithm like just xoring a few plaintext
> characters...
It's between the two. For export reasons it was designed to be
breakable, but not easily breakable. There's a clever attack that can
break it in a few hours with a few hundred bytes of known compressed
plaintext (it can operate with as little as 13 bytes, but is much
slower). Mounting the attack in practice is not always easy, but
still, pkzip's encryption cannot be called secure. If you want real
security, use a real algorithm like AES.
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: DES key replacement.
Date: Thu, 29 Mar 2001 10:17:09 +0200
In the 10^9 bit range. Check cesg.gov.uk and the SSL/TLS protocol.
Yaniv Sapir wrote:
> Hi all.
>
> When using DES for encryption of long messages, is it a common practice to
> replace the 64-bit key once in a while? If so, how frequent?
>
> TIA,
> Yaniv.
------------------------------
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
From: [EMAIL PROTECTED]
Subject: Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be
Date: Thu, 29 Mar 2001 08:27:05 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Lutz Donnerhacke wrote:
> * Rich Wales wrote:
> >Regarding older PGP's and this attack, PGP 2.6.3ia performs one (and
> >apparently only one) of the RSA tests recommended in the ICZ paper
> >(n=pq is verified in keymgmt.c, line 626).
> >
> >I'm not sure whether this single test suffices to make PGP 2.6.3ia
> >immune to the ICZ attack or not.
>
> It does not.
why ?
your test does the same thing (checks if n==pq), doesn't it ?
(another part of your test checks if sig is valid after signing)
> >Lutz Donnerhacke's latest 2.6.3in release includes additional tests
> >(in rsaglue1.c and rsaglue2.c), which are intended to confirm the
> >validity of the secret key, and thus guard against the ICZ attack.
>
> Yep.
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
^--GPG for Win32 (supports loadable modules and IDEA)
^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOsLVsDBaTVEuJQxkEQL0IgCfSJ7lcOQFXvOonddsqwqW1FUW2X8AoIoZ
aEqLPQaEu1oJ9O+Sy7S1VK0t
=wgsR
=====END PGP SIGNATURE=====
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Estimation of the keygen time
Date: Thu, 29 Mar 2001 10:30:14 +0200
<posted & mailed>
Chenghuai Lu wrote:
> Paul Rubin wrote:
>>
>> Chenghuai Lu <[EMAIL PROTECTED]> writes:
>> > I'm using the vendor-supplied CSP and can't be completely sure what
>> > it's doing. But yes, it typically takes 30-60 seconds. Doing it on
>> > the workstation takes under a second. The keygen time on the card is
>> > about what I'd expect based on the signing speed of the card.
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> > Can Rubin or some one share with me the method how to estimate the
>> > keygen time based on signing speed?
>> >
>> > Thanks.
>>
>> Basically you'd expect keygen to take on the order of 30x longer than
>> signing, based on the idea that you run a Fermat test (i.e. a modexp)
>> on a bunch of candidate primes until you get two that pass the test.
>
> In my program, what I found is, after taking out all composite divisible
> by small primes less than 255, there remain 52 odd numbers still need
> testing. And the first part, sieving out composites also takes time,
> about 5.2 second to try 255 odd numbers. For each power-module
> operation(521 bits), it takes about 0.11 s. So roughly, the time for
> generating a 521 bit prime is a little less than 15 seconds. That is my
> estimation. Since transferring APDU to or from the card also takes time.
> Did you substract that time when you calculate the signing speed?
>
> Thank you for your discussion.
>
> Lu
That seems like an awful long time for some pretty basic filtering - which
should go faster than even a single modular exponentiation.
Try the technique I use in the BeeCrypt crypto library: take a number which
is the product of the first N small primes (up to your preference - I use a
number which is equal in bitsize to the candidates), and compute the gcd of
this number and your prime candidate. If the gcd is one, your candidate has
passed all tests in one operation. That should speed up your test.
If you want to examine my code, see http://beecrypt.virtualunlimited.com.
Sincerely
Bob Deblier
Virtual Unlimited
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Breaking a DES encrypted code.
Date: Thu, 29 Mar 2001 10:30:25 +0200
William Hugh Murray wrote:
>
> What is more, we use the otherwise unused cycles on the desktop. The
> cost of these cycles approximates zero. That is to say, if we had not
> used them for cryptanalysis, we would not have used them at all.
Long time ago, I learned of projects to utilize the power
of a network of computers left latent by the ones at the
terminals. For most commercial firms, that power could
be fairly substantial, expecially at night. Does anyone
happen to know whether this is in vogue? (I don't mean
projects of internet computing for factoring numbers, etc.)
M. K. Shen
------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Re: WinZip and other Zip Archivers
Date: Thu, 29 Mar 2001 10:42:21 +0200
Kinda enough for me now, hehe. People who can hack that can probably hack my
system directly and get the sources and so on through my windows security
holes.... and they aren't that valuable. Yet :)
Thanks very much for the info :)
> security, use a real algorithm like AES.
I will later in my project. No question.
--
--
Moritz "Thygrrr" Voss
Client-Server & OpenGL Developer
http://www.optionoverkill.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Malicious Javascript in Brent Kohler post
Date: Thu, 29 Mar 2001 10:38:08 +0200
"Henrick Hellstr�m" wrote:
>
> An ActiveX can do virtually anything an exe can do. You might convert any
> kind of application into an automation server, and an ActiveX control is
> just a special case of an automation server with some additional methods in
> it's interface. That is, an ActiveX control must have entry points for
> certain COM calls, but besides that there are few restrictions. For
> instance, ActiveX is commonly used as a way to use components coded and
> compiled in C++ in VB code.
Thanks. Just to be entirely sure that I understand, let
me ask once again: If I get something from the internet
and I don't have the knowledge to examine whether it
could be malicious, is a good virus scanner sufficient
for protection? If not, is there any secure mechanism
available or do I otherwise have to leave the stuff
untouched, if I want to be absolutely secure? Thanks.
M. K. Shen
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Clarification about the Czech attack to PGP
Date: Thu, 29 Mar 2001 11:05:44 +0200
Lutz Donnerhacke wrote:
> PGP was created on a set of principles:
> 1 Run on a single user, single tasking OS without networking capabilities.
Email encryption without network capabilities and for one user?
So, it was envisioned that the typical user would send encrypted emails to himself
on his local machine only?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
** 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
******************************
