Re: newbie: 64bit, 512 or 1024 ?
In all honesty I would recommend against getting a 64-bit certificate. And I would recommend just as strongly against a 512-bit certificate. There's 2 large reasons for this. First the 64-bit, the RSA DES Challenge III taught us that using second rate, 3 year old technology, in a relatively poorly funded manner you can break 56-bit security in under a day. Given proper funding, proper modern technology, and 1 day it is certainly possible to break 64-bit security. Can you risk having only 1 day worth of security? How about next year when it becomes 12 hours? 512-bit factoring has been done (Code Book challenge). It took a network of 100 machines working during idle time a couple of months, followed by a 4 processor Alpha (2 years old) running about a week. Again this was not a best of breed attack, 100 machines is available to me right now if I really tried, I could probably get half of them from the office I'm in right now. The equivalent of the Alpha is easy enough to come by now, just slap that much RAM in a high end P4 and give it a couple weeks. So can you afford to only have a couple of weeks of security? This attack would cost much less than the 64-bit attack. I really don't think you should use a 512-bit certificate or use anything below 80-bit security, preferably 128-bit. Technically you can use a 1024-bit public key with 64-bit security, but whether or not they'll sign it is up to Thawte. Joe - Original Message - From: John Peters [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 01, 2001 3:49 PM Subject: newbie: 64bit, 512 or 1024 ? I want to order a $125 64bit thawte certificate. I see almost everyone using 1024 to generate the private key, but it says on the thawte website that 1024 is for the 128bit certificates. Does it matter if use 512 or 1024 to generate the private key? Regards John Peters _ Get your FREE download of MSN Explorer at http://explorer.msn.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
The AES question (was Re: Stronger SSL Encryption)
- Original Message - From: Francis DeLaMaza [EMAIL PROTECTED] BTW, what is AES? - Original Message - From: Francis DeLaMaza [EMAIL PROTECTED] Any disadvantages to AES? Who is developing it? Opensource? AES is the soon to be government standard titled Advanced Encryption Algorithm, it has become commonplace to use the term AES to refer to a cipher that is actually names Rijndael. The name change will only be complete after the FIPS is published. It is a 128-bit block cipher, supporting keys of 128/192/256 bits. Because the cipher is Rijndael it also supports block and key sizes that are any multiple of 32-bits, but only 128x128/192/256 will be the official standard. Originally created in Europe for the AES competition, by Joan Daemen and Vincent Rijmen. Rijndael benefits a large body of attack knowledge from Square. And the specification can be found from http://csrc.nist.gov/encryption/aes/rijndael/ along with a significant body of information. As with any recent cipher it's security is in question. However Rijndael has survived 2+ years of intense public scrutiny, of the final 5 it was chosen because it was fastest. The other 4 were MARS, Twofish, RC6, and Serpent. General concensus was that the only real competitors were Twofish, Serpent, and Rijndael. Of these Rijndael was universally fast, and the most well balanced cipher. However of the 3 that were identified as real competitors, Rijndael has the smallest security margin, and is believed to be the weakest. This makes no difference because with all 3 contending finalists, in fact with all the finalists there are no attacks better than brute-force known. In spite of this it is worth noting that during the final AES conference the developers for each algorithm were asked barring their own cipher which cipher they would like to see as AES. With the obvious exception of the Rijndael team every team stated they would like to see Rijndael crowned. Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: What happened when certificate is revoked ?
You should not be able to use an expired/revoked certificate to successfully complete an SSL handshake. This actually occurs out of band, the certificate has the information in it for any individual to contact a server and verify the validity of it. However I know Microsoft utilities have a tendency to not verify the certificates by default, so it is entirely possible that you could successfully complete an SSL connection with a revoked certificate. Joe - Original Message - From: "Dou Qiang" [EMAIL PROTECTED] To: "OpenSSL" [EMAIL PROTECTED] Sent: Wednesday, March 07, 2001 11:11 PM Subject: What happened when certificate is revoked ? I am always wondering about what happened when server or client certificate is revoked. Can I use a revoked certificate to pass the SSL handshake process ? Are there any Certificate checking operations in the SSL protocol ? Dou Qiang [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS 12 and spitting out (DSA) public keys (code request)
- Original Message - From: "Dr S N Henson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Joseph Ashwood wrote: Does anyone have some code onhand that will take a PKCS 12 file, lookup a known name, grab a DSA key and hand it back? [snip most of what I said] Alternately, does anyone know where in the which file the openssl pkcs12 takes care of such things? The PKCS#12 standard does support public key storage other than as part of a certificate. That's as expected. The current code extracts the private key and calculates the public key from it. I'm not using much of the current code, I'm even generating my own prime fields/ Do you specifically need more than one private key in a PKCS#12 file? If not and you have a corresponding certificate then PKCS_create() and PKCS12_parse() may be of use. I'll look into it. Otherwise you'll generate and pull apart the files manually using like the pkcs12 utility currently does. That's what I was hoping to avoid. But I'll subject myself to it if I have to. Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: symmetric key produced by Diffie-Helman alg. not equal in both sides
And let me say it again, this time with a bit more information. Windows runs on x86, which is little endian, Linux I assume you are also running on little-endian (x86). Solaris I assume you are running on UltraSPARC which if I remember correctly is big-endian. You are not transferring your keys correctly, they need to be endian-normalized. Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Setting the bit to 128
Ok, now we're getting somewhere. It's a misunderstanding of what the values mean (I'm going to over simplify some to make the points clearer). When an SSL connection is 40-bit, it means that the negotiated key size is 40-bits. When you ask to generate an X-bit certificate, that refers to the length of the RSA modulus, anything less than 768-bits is considered insecure. The bit-ness of the certificate has no official bearing on the SSL keys. What does have a very significant effect is the browser (which you said was 128-bit), and the web server (which you only mentioned it being apache, I assume with an SSL addon). Either the browser or the server is limiting the choices to 40-bit symmetric keys. Joe smime.p7s
Re: symmetric key produced by Diffie-Helman alg. not equal in both sides
It's ok, we all make mistakes. I've had similar bugs, probably 3 dozen times, with various amounts of time to find them. Joe - Original Message - From: "Bruker, Ohad" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 16, 2001 2:09 PM Subject: RE: symmetric key produced by Diffie-Helman alg. not equal in both sides Thanks a lot Joe, I changed the code and now I transfer the DH public value (struct BIGNUM) in the binary form and it works fine. Most probably it was not endian-normalized (even though I put attention to it, because it's a multi platform application). I am too embarrassed to admit that I sent the BIGNUM as is... so maybe it's a sign to do things right!!! Thanks a lot again for your patient. Ohad. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: What does the e-value do?
First a bit of background. RSA is this:
p,q primes
N=pq
e=prime that is not a factor of p-1 or q-1 and not equal to p or q
d = e^-1 mod (p-1)(q-1)
public key = {e,N}
private key = {d, N}
Encryption = X = M^e mod N
Decryption = M = X^d mod N
The e-value you see in the call is the value e above. The recommendation of
using 3 or 65537 is a speed decision, and I would definitely recommend 65537
over 3 for security reasons.
Joe
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: symmetric key produced by Diffie-Helman alg. not equal in both sides
- Original Message - From: "Bruker, Ohad" [EMAIL PROTECTED] All the basic stuff you mentioned is implemented right. It is already *WORKING* on Linux and Windows platforms without any problems. I encounter this problem probably because Solaris does not support random device !!! The manual seeding of the PRNG probably cause this problem (symmetric key in both sides is not equal). Thanks, Ohad. The PRNG has absolutely nothing to do with the negotiation. The PRNG is only used when creating the keys and their parameters, after that no randomness enters or leaves the system. The DH exchange is simply: Pka, Pkb = public keys for A and B Ska, Skb = private keys for A and B P = a large prime G = a generator for P (typically a small prime, 2 or 5 is common) Ska, Skb = Random numbers Pka = G^Ska mod P Pkb = G^Skb mod P the shared secret is K1 = Pka^Skb mod P K2 = pkb^Ska mod P K1=K2 Because the public key can also be any random value, the PRNG is not an issue (as long as it doesn't generate 0). If you're sure that modular exponentiation is working and that the keys are being transferred correctly, then it must work, regardless of the PRNG involved. That's why I was asking those questions. If you can dissect the implementation and make sure that each of these is performing properly, DH key exchange will work correctly. Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Encrypt/Decrypt fails
Just a guess, but a fairly educated one, try setting flen to 1 byte (or even
1 bit) smaller than the key. What I suspect is happening is you are
sometimes trying to encrypt values that are larger than the modulus so
you're getting a modular reduction of the value encrypted.
Joe
- Original Message -
From: "Jan Zoellner" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 14, 2001 2:25 PM
Subject: RSA Encrypt/Decrypt fails
Hello,
I have a problem for which I found no real solution in the manual or the
list archives.
The basic idea is to encrypt data using RSA_private_encrypt and retrieve
it
using RSA_public_decrypt. For RSA_private_encrypt, I set flen to
RSA_size()
to encrypt just one block and decrypt it later. If there is more data, it
is processed blockwise in a loop.
RSA_NO_PADDING is used (yeah, I know one shouldnt do that). For most
blocks, the decryption works fine. For some block it just doesnt work. I
dont get any error reports, the decrypted data just isnt what it should
be.
Below you find an excerpt from the code (some NULL checkings and the like
omitted). What am I doing wrong? Once again: There is no overlapping
memory
or the like, the process functions properly in most cases, but in some
cases (it seems to be depending on the data actually!) the routine fails,
either at encryption or decryption (or even both?).
Ciao
Jan
// get key
rsaStruct = PEM_read_RSAPrivateKey(fp, NULL, NULL, password);
// srcLen is original length given as a function parameter
unsigned long destLen = srcLen;
// Now pad to correct block size, resulting in a destination length of
// N*RSA_size()
unsigned long blocklength = RSA_size(rsaStruct);
destLen = (((destLen - 1)/ blocklength) + 1) * blocklength;
// create destination array
dest = new unsigned char[destLen];
memset(dest, 0, destLen);
// create source array
unsigned char *tmpSrc = new unsigned char[destLen];
memset(tmpSrc, 0, destLen);
// copy original source data, result is an array of correct length
containing
// the source and trailing zeroes
memcpy(tmpSrc, src, srcLen);
// now encrypt blockwise
for (unsigned long i = 0; i destLen; i+= blocklength) {
if (blocklength!=RSA_private_encrypt(blocklength, (tmpSrc+i),
(dest+i), rsaStruct, RSA_NO_PADDING)) {
printf("RSA Encrpytion Error.\n");
delete [] dest;
delete [] tmpSrc;
return 0;
}
}
// and now decrypt the data again
// array to contain the decrypted data
unsigned char *tmpDest = new unsigned char[destLen];
for (i = 0; i destLen; i+= blocklength) {
if (blocklength!=RSA_public_decrypt(blocklength, (dest+i),
(tmpDest+i), rsaStruct, RSA_NO_PADDING)) {
printf("RSA Decryption Error.\n");
delete [] dest;
delete [] tmpDest;
delete [] tmpSrc;
return 0;
}
}
--
Jan Zoellner - VidSoft GmbH
eMail: [EMAIL PROTECTED] - Tel: ++49 351 435 34 17
WWW: http://www.vidsoft.de
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: symmetric key produced by Diffie-Helman alg. not equal in both sides
If all you're callling is DH_generate_key(...) then it should create different keys. That function call only generates the public and private keys. What you need to do is: DH_generate_parameters(...) transfer the parameters between machines so that they are both working in the same field DH_generate_key(...) the machines swap public keys DH_compute_key(...) the output of DH_compute_key on both machines should be identical. If that's not identical I can help you build the computations from scratch and that will work (it's not much harder than calling the functions above). Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: symmetric key produced by Diffie-Helman alg. not equal in both sides
Most likely these will sound like really stupid questions, but honest they're the same questions I've had to ask myself to find the answers. Have you verified that the parameters used by both sides are the same? Have you verified that the public key is transferred correctly? I'm just trying to narrow down where the problem is. If these aren't the problem than have you verified that g does not divide p? (it shouldn't if you called DH_generate parameters but since there's obviously a problem . . . ) Have you checked to see that the openSSL implementation computes a set of test vectors for exponentiation properly? Joe - Original Message - From: "Bruker, Ohad" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 14, 2001 6:25 PM Subject: RE: symmetric key produced by Diffie-Helman alg. not equal in both sides Of course I'm calling the DH_compute_key(...) after sharing the DH public key both sides. The symmetric keys are already produced successfully on Windows and Linux. Thanks, Ohad. -Original Message----- From: Joseph Ashwood [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 6:14 PM To: [EMAIL PROTECTED] Subject: Re: symmetric key produced by Diffie-Helman alg. not equal in both sides If all you're callling is DH_generate_key(...) then it should create different keys. That function call only generates the public and private keys. What you need to do is: DH_generate_parameters(...) transfer the parameters between machines so that they are both working in the same field DH_generate_key(...) the machines swap public keys DH_compute_key(...) the output of DH_compute_key on both machines should be identical. If that's not identical I can help you build the computations from scratch and that will work (it's not much harder than calling the functions above). Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BN_mod_inverse problem
I've found a problem with BN_mod_inverse, in particular when it is called many times in quick succession when verifying DSA signatures. Originally this showed up when use DSA_do_verify, so I wrote my own, and I've isolated the problem as being in BN_mod_inverse. It seems to only occur on about 0.2 % of the data sets, and I've only verified it when running in fast succession (several a second) on a Pentium III @ 750 MHz running windows2000, I've found a dataset of 2 where the second fails verification while the first succeeds regardless of the order of the two of them. Has anyone else experienced this or closely related problems? Is there a known workaround? Joe __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
