Cryptography-Digest Digest #757, Volume #13 Tue, 27 Feb 01 11:13:00 EST
Contents:
Re: How to find a huge prime(1024 bit?) ("Jakob Jonsson")
encryption and information theory (Andreas Moser)
Re: encryption and information theory (Mok-Kong Shen)
Re: A remark on polyalphabetical substitutions (Mok-Kong Shen)
Re: Help Please !!!!!!!!!!!! (Frank Gerlach)
DH Key Agreement in SSL (=?iso-8859-1?Q?Fr=E9d=E9ric?= Donnat)
Re: Arcfour in Ada (Larry Kilgallen)
Re: Safe to use DSS key for DH? (DJohn37050)
Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep Boys
("Mxsmanic")
In RSA, how d is calculated? ("david Hopkins")
In RSA, how d is calculated? ("david Hopkins")
Help:In RSA, how d is calculated? ("david Hopkins")
On RC4 in C (William Hugh Murray)
Re: encryption and information theory (SCOTT19U.ZIP_GUY)
BeeCrypt version 2.0.0 released (Bob Deblier)
BeeCrypt version 2.0.0 released (bis) (Bob Deblier)
Re: In RSA, how d is calculated? (Doug Stell)
Re: Safe to use DSS key for DH? (Doug Stell)
Re: Safe to use DSS key for DH? ("Michael Scott")
Re: Rnadom Numbers ("Simon Johnson")
----------------------------------------------------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: How to find a huge prime(1024 bit?)
Date: Tue, 27 Feb 2001 11:13:43 +0100
"Thomas Boschloo" <[EMAIL PROTECTED]> wrote in the message
news:[EMAIL PROTECTED]...
> Well, I want to thank you both for your replies and am somewhat
> reassured that PGP 263i is safe because of the book published by 'Brandt
> and Damg�rd' (I do not know their names however, nor do I posses the
> book mentioned. At one time I wanted to order the book about EC by Neil
> Koblitz from the same publisher, but it was far to expensive for me).
The Brandt-Damg�rd paper is available from
http://imailab-www.iis.u-tokyo.ac.jp/limit/Papers/Crypto_Eurocrypt/HTML/AUTH
ORS.HTM
The relevant discussion is in section 4. By the way, their result is based
on the assumption that a certain generalization of the prime number theorem
is true. While "everybody" seems to believe that this generalization is
indeed true, it has not been formally settled AFAIK. For some related
discussion, see
http://www.mathsoft.com/asolve/constant/hrdyltl/hrdyltl.html
Jakob
------------------------------
From: Andreas Moser <see@http://www.ztop.freeserve.co.uk>
Subject: encryption and information theory
Date: Tue, 27 Feb 2001 10:30:33 +0000
A question regarding the information content (entropy) of
encrypted messages:
Does the encryption change the entropy, i.e. does the
encrypted message still reflect the information content of
the original message? Say the original message had an
entropy of 1 kbit, then use, say, PGP encryption, does it
increase?
If the answer is yes, where does the additional information
come from, and if the answer is no, isn't there a way to see
through the encryption?
Just curious...
Andreas
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: encryption and information theory
Date: Tue, 27 Feb 2001 13:16:36 +0100
Andreas Moser wrote:
>
> A question regarding the information content (entropy) of
> encrypted messages:
> Does the encryption change the entropy, i.e. does the
> encrypted message still reflect the information content of
> the original message? Say the original message had an
> entropy of 1 kbit, then use, say, PGP encryption, does it
> increase?
>
> If the answer is yes, where does the additional information
> come from, and if the answer is no, isn't there a way to see
> through the encryption?
Pending answers by experts, I would say that there can
be an increase in entorpy coming from that of the key
employed. I am yet ignorant of a good way of determining
the entropy of a given bit sequence, though.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A remark on polyalphabetical substitutions
Date: Tue, 27 Feb 2001 14:05:56 +0100
Addendum:
We mention that an application of polyalphabetical substitution
is post-processing the bit sequences output from PRNGs for
reducing their susceptibility to prediction.
M. K. Shen
------------------------------
From: Frank Gerlach <[EMAIL PROTECTED]>
Subject: Re: Help Please !!!!!!!!!!!!
Date: Tue, 27 Feb 2001 14:13:53 +0100
it would most probably be nice to remove the names of the users
involved, before posting.
They might use the same password somewhere else....
------------------------------
From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Donnat <[EMAIL PROTECTED]>
Subject: DH Key Agreement in SSL
Date: Tue, 27 Feb 2001 13:28:01 GMT
Il s'agit d'un message multivolet au format MIME.
==============742DB024A2A13F5284778064
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi
I'd like to know how i migth use the secret generate with a DH Key
Agreement in SSL.
In SSL DH Key Agreement is used to generate a shared secret and this
secret is use as a pre master secret but the size don't match so i'd
like to know if the most sigificant or the least signifiant bytes are
used !
If someone can help me !
Best Regards Fred
==============742DB024A2A13F5284778064
Content-Type: text/x-vcard; charset=us-ascii;
name="frederic.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Carte pour Fr�d�ric Donnat
Content-Disposition: attachment;
filename="frederic.vcf"
begin:vcard
n:Donnat;Frederic
tel;fax:0470480031
tel;work:0470480030
x-mozilla-html:FALSE
org:I.C.R. Informatique;ALLIER (03)
version:2.1
email;internet:[EMAIL PROTECTED]
title:Ingenieur Developpement Logiciel et Materiel
adr;quoted-printable:;;Espace Boudeville=0D=0A;Dompierre sur Besbre;;03290;France
end:vcard
==============742DB024A2A13F5284778064==
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Crossposted-To: comp.lang.ada
Subject: Re: Arcfour in Ada
Date: 27 Feb 2001 08:31:46 -0500
In article <[EMAIL PROTECTED]>, Benjamin Goldberg
<[EMAIL PROTECTED]> writes:
> Thomas Boschloo wrote:
>> Why did you decide to go for arcfour and not the AES
>> http://www.nist.gov/aes ? AFAIK Arcfour or RC4 was originally a
>> 'security by obscurity' cypher (Arcfour was (now illegal) reverse
>> engineered from RC4 by www.rsa.com).
>
> Arcfour is not illegal, but the name "RC4" is trademarked. To use a
> cipher called "RC4" without liscencing that trademark is illegal. To
> use the algorithm is perfectly legal.
>
> The algorithm of RC4 was a trade secret, meaning that some "security by
> obscurity" was involved, but in spite of that, the algorithm is still
> fairly secure.
I am not convinced that any "security by obscurity" was involved.
Do you have any references ? The fact that something was hidden
does not prove that the reason for hiding it was security. RSADSI
made considerable revenue from keeping the RC4 algorithm hidden.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 27 Feb 2001 13:39:32 GMT
Subject: Re: Safe to use DSS key for DH?
See IEEE 1363 for discussion on attacks. Also, you should use 1024 bit p with
a 160 bit q.
Don Johnson
------------------------------
From: "Mxsmanic" <[EMAIL PROTECTED]>
Subject: Re: The Key Vanishes: Scientist Outlines Unbreakable Code, Read it and Weep
Boys
Date: Tue, 27 Feb 2001 14:08:16 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You may not need this much data. Fiber optic systems
> have been demonstrated at close to a terabit per second.
How do you string fiber between you and the satellite?
Besides, it's not the transmission speed I worry about; it's the
_generation_ speed. Where do you find all those _completely random_
bits?
> It's true that the papers in the literature don't
> discuss what happens if two people use the same data
> stream. But it's probably still okay.
It's a cinch to crack a OTP if you have two ciphertexts that use the
same key.
> You are mistaken to think that you just index into
> the data stream and use it for a OTP. Rather, the
> communicators share a PRNG which indexes randomly
> into the data stream, and these bits are then xored
> together to form the OTP. This means that different
> groups can use the same data stream and have completely
> different pads.
If their PRNGs are so insecure that they need to XOR with a truly random
source, why bother with the PRNGs? And if the PRNGs are so secure that
no truly random source is required, why the need to XOR with the random
source from the satellite? I really don't see them buying anything with
the satellite. If their PRNG is not secure, and they use bits from the
satellite, and anyone else overlaps a message with theirs, cryptanalysis
is easy.
There are so many holes in any _practical_ implementation of this scheme
that I don't see how it can be much more than a thought experiment.
> True, except the secret key does not determine only
> the starting point, but also how the bits are selected
> and skipped and xored together to form the OTP.
That has no effect on the security of the algorithm. The secrecy of the
cryptosystem as a whole depends on the effective key length of the
secret portion of the system. In this case, the effective key length
isn't so very great.
> He'll just encrypt the bits and charge for the decryption
> key...
Encryption of a random stream of bits isn't encryption at all.
------------------------------
From: "david Hopkins" <[EMAIL PROTECTED]>
Subject: In RSA, how d is calculated?
Date: Tue, 27 Feb 2001 14:55:25 GMT
N = P x Q = 37x 13= 481
PHI = (P-1)(Q-1) = 432
The public exponent E will be generated by the computer
so that the greater common divisor of E and PHI is 1.
In other words, E is relatively prime with PHI.
E = 5
N and E are your public keys. Your private key (D) is the
inverse of E modulo PHI.
By using extended Euclidian algorithm, the private key, D, is 173
how d is calculate?
thank you.
------------------------------
From: "david Hopkins" <[EMAIL PROTECTED]>
Subject: In RSA, how d is calculated?
Date: Tue, 27 Feb 2001 14:55:25 GMT
N = P x Q = 37x 13= 481
PHI = (P-1)(Q-1) = 432
The public exponent E will be generated by the computer
so that the greater common divisor of E and PHI is 1.
In other words, E is relatively prime with PHI.
E = 5
N and E are your public keys. Your private key (D) is the
inverse of E modulo PHI.
!!! I don't understand here. How d is calculates.
By using extended Euclidian algorithm, the private key, D, is 173
how d is calculate?
Thank you.
------------------------------
From: "david Hopkins" <[EMAIL PROTECTED]>
Subject: Help:In RSA, how d is calculated?
Date: Tue, 27 Feb 2001 14:55:26 GMT
N = P x Q = 37x 13= 481
PHI = (P-1)(Q-1) = 432
The public exponent E will be generated by the computer
so that the greater common divisor of E and PHI is 1.
In other words, E is relatively prime with PHI.
E = 5
N and E are your public keys. Your private key (D) is the
inverse of E modulo PHI.
By using extended Euclidian algorithm, the private key, D, is 173
how d is calculate?
Thank you.
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.ada
Subject: On RC4 in C
Date: Tue, 27 Feb 2001 15:20:11 GMT
Larry Kilgallen wrote:
> In article <[EMAIL PROTECTED]>, Benjamin Goldberg
><[EMAIL PROTECTED]> writes:
> > Thomas Boschloo wrote:
>
> >> Why did you decide to go for arcfour and not the AES
> >> http://www.nist.gov/aes ? AFAIK Arcfour or RC4 was originally a
> >> 'security by obscurity' cypher (Arcfour was (now illegal) reverse
> >> engineered from RC4 by www.rsa.com).
> >
> > Arcfour is not illegal, but the name "RC4" is trademarked. To use a
> > cipher called "RC4" without liscencing that trademark is illegal. To
> > use the algorithm is perfectly legal.
> >
> > The algorithm of RC4 was a trade secret, meaning that some "security by
> > obscurity" was involved, but in spite of that, the algorithm is still
> > fairly secure.
>
> I am not convinced that any "security by obscurity" was involved.
> Do you have any references ? The fact that something was hidden
> does not prove that the reason for hiding it was security. RSADSI
> made considerable revenue from keeping the RC4 algorithm hidden.
Arguably. One can also argue that that they have made a lot of money publishing high
quality code
cheaper than others can replicate it for themselves. When MS, not to mention
Kilgallen, does
that we call it software publishing. We say they made money publishing, they made
money on what
they published. We do not say that they made money by not publishing, on what they
chose not to
publish. One does not describe unpublished MS design documents or source code as
"hidden," much
less secret, simply because they do not publish them. One has no obligation to
publish something
in one form or language simply because one chooses to publish it in another. We do
not call
something published in one language hidden or secret because it is not published in
another.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: encryption and information theory
Date: 27 Feb 2001 15:13:03 GMT
see@http://www.ztop.freeserve.co.uk (Andreas Moser) wrote in
<97fvk8$j6f$[EMAIL PROTECTED]>:
>A question regarding the information content (entropy) of
>encrypted messages:
>Does the encryption change the entropy, i.e. does the
>encrypted message still reflect the information content of
>the original message? Say the original message had an
>entropy of 1 kbit, then use, say, PGP encryption, does it
>increase?
>
>If the answer is yes, where does the additional information
>come from, and if the answer is no, isn't there a way to see
>through the encryption?
>
>Just curious...
>Andreas
I will answer this in a indirect way. Suppose
the enemy knows that there is only 1 of 10 messages
that you are sending to a friend and that the enemys job
is to find the message.
If you encrypt the message and it is intercepted.
The enemy has to figure out which message it is. If the
encryption you choose is known by the enemy. He could test
keys and use other methods to try to see if one of the ten
messages could have been encrypted to the intercepted cipher
text. Lets suppose you used a GOOD encryption and that there
exists different KEYS such that any one of the ten messages
could have been sent. In this case no change in entropy.
Know lets suppose you used something the big boys want you
to use. You sent the message with PGP. Know the bad guys
start to analyse the ciphertext. The fact is with PGP and
a given ciphertext there is most likely only one message that
could have been sent. They may have to test many keys. THey
may torture you or your friend to get the keys. But as soon as
one works they know exactly which message you sent. The proof
is in the fact that it most likely only one reverse key could
exist and false keys will not lead to another of your ten messages.
I hope this anwsers your question.
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: Bob Deblier <[EMAIL PROTECTED]>
Subject: BeeCrypt version 2.0.0 released
Date: Tue, 27 Feb 2001 16:35:06 +0100
Hi all,
I'm pleased to announce release 2.0.0 of the BeeCrypt crypto library. This
version offers better support for Microsoft Visual C++, and should be easy
to compile on POSIX compatible platforms.
The changelog for this release:
- Changed mp32barrett struct and operations to be multithread-safe; this
required a change in API.
- Changed hashFunction struct to incorporate internal block size parameter.
- Changed HMAC algorithm and file names to match names in RFC 2104.
- Changed SHA-1 C code for slightly faster results.
- Changed detection of entropy devices.
- Changed most void-returning functions to return int for error conditions.
- Changed beecrypt-java class names in javaglue.
- Added RSA keypair generation.
- Added RSA private & public key operations.
- Added SHA-256 hash function.
- Added HMAC-MD5 and HMAC-SHA-256 keyed hash functions.
- Added PKCS#5 padding.
- Added DHAES encryption scheme.
- Added Microsoft Visual C support, added Makefile.mak for this purpose.
- Added Solaris/Sparc Forte C 64 bit support.
- Added configure --disable-optimized option (disables assembler &
processor-specific optimizations).
- Fixed bug in SHA-1 assembler code for Pentium, where local variables were
used below the current stack pointer; this could cause a problem if the
routine was interrupted. This was pointed out by Richard Clayton.
- Fixed bug in (certain cases of) modular inverse computation.
- Fixed buffer overrun in base64 encoding. This was pointed out by Jon
Sturgeon.
- Fixed various minor bugs.
- Renamed text files to match automake conventions.
Sincerely,
Bob Deblier
Virtual Unlimited
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: BeeCrypt version 2.0.0 released (bis)
Date: Tue, 27 Feb 2001 16:40:50 +0100
I forgot to include the URL in my previous posting - sorry about that:
http://beecrypt.virtualunlimited.com/
Sincerely,
Bob Deblier
Virtual Unlimited
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: In RSA, how d is calculated?
Date: Tue, 27 Feb 2001 15:35:07 GMT
On Tue, 27 Feb 2001 14:55:25 GMT, "david Hopkins"
<[EMAIL PROTECTED]> wrote:
>N = P x Q = 37x 13= 481
>PHI = (P-1)(Q-1) = 432
>The public exponent E will be generated by the computer
>so that the greater common divisor of E and PHI is 1.
>In other words, E is relatively prime with PHI.
>E = 5
>N and E are your public keys. Your private key (D) is the
>inverse of E modulo PHI.
>
>By using extended Euclidian algorithm, the private key, D, is 173
>
>how d is calculate?
D = (E)^-1 (mod Phi[N]) = (E)^(Phi[N]-1) (mod Phi[N])
= (5)^(P-1)*(Q-1)-1 (mod (P-1)*(Q-1))
= (5)^431 (mod 432) = 173
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Safe to use DSS key for DH?
Date: Tue, 27 Feb 2001 15:39:25 GMT
On 27 Feb 2001 04:00:26 -0000, lcs Mixmaster Remailer
<[EMAIL PROTECTED]> wrote:
>Suppose you have a DSS key, of typical size: prime modulus p of 1024 bits,
>generator g generating a subgroup of size q, where q is 160 bits.
>
>Would it be safe to use this key for DH and/or ElGamal encryption?
>Would you still get ~80 bits of security (based on the modulus size)?
If you look at the KEA spec, you will discover that:
1) KEA is a dual D-H exchange and
2) KEA is specified to use DSS parameters and keys.
That tells me that the Agency that gave us KEA says that yes it would
be safe.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Safe to use DSS key for DH?
Date: Tue, 27 Feb 2001 09:43:16 -0600
"lcs Mixmaster Remailer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Suppose you have a DSS key, of typical size: prime modulus p of 1024 bits,
> generator g generating a subgroup of size q, where q is 160 bits.
>
It can't hurt to use a Lim-Lee Prime, which ensures that there are no small
subgroups (other than the trivial group of order 2 which can be easy checked
for). A Lim-Lee prime p=2.q.q1.q2.. +1, where q is the order of the group
you want to work in, and q1, q2 etc are slightly larger. The time it takes
to generate a Lim-Lee prime is only marginally slower than a general
DSS-type prime.
Whether or not a small sub-group attack is possible depends on the protocol.
It doesn't affect DSS or DH.
Mike Scott
> Would it be safe to use this key for DH and/or ElGamal encryption?
> Would you still get ~80 bits of security (based on the modulus size)?
>
> Thanks very much!
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Rnadom Numbers
Date: Tue, 27 Feb 2001 16:09:52 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Douglas A. Gwyn wrote:
> >
> > Simon Johnson wrote:
> > > yeah, good point. I assume that this question cannot be answered
> > > then until the problem surrounding p=np is solved, right?
> >
> > P?=NP has absolutely nothing to do with whether a PRNG output can
> > be successfully cryptanalyzed.
This is stating the question again i think.... but: "is it possible to show
that no attack can ever exists for an algorithm without P?=NP? below a
certain complexity?"
I simply assumed (probably incorrectly) that without this proof we couldn't
say with total certainty that some algorithm had no solution faster than
brute-force.
> --
> A solution in hand is worth two in the book.
------------------------------
** 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
******************************
