some questions about openssl
hi all: My quesitons about openssl are below: 1. I want to take advantage of RSA and SHA in openssl for secure booting. Can they run as standalone program, that means they can run without libc support. 2. I want RSA and sha authentication run in DRAM instead of flash, such that the speed will be faster. Is that possible to fix the link address of openssl? -- Regards, miloody __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH session Key length
Look, the typical way you'd use the DH shared secret would be to hash it using an appropriate hash function. I personally like using Tiger with AES-192, YMMV. On Tue, Apr 19, 2011 at 3:56 PM, ikuzar razuk...@gmail.com wrote: So, have I to generate a prime with length = 3200 bits ?, ( the corresponding exponent will belong to 3200-bit MODP group ) in order to generate an AES 128 session key ? ( I use 2 as generator ). Here http://tools.ietf.org/html/rfc3526, it is said : The new Advanced Encryption Standard (AES) cipher [AES], which has more strength, needs stronger groups. For the 128-bit AES we need about a 3200-bit group [Orman01]. ..; in this IETF, 6 MODP groups are exposed. 3200-bit is not among this groups... Concretly, what should I write to obtain AES 128 session key? i Wrote something like this ( in command line ): openssl dhparam -outform PEM -out dhParams.pem -2 3200 Then I decode dhParams.pem into internal C struct: dh. Then I call DH_generate_key(DH *dh); , then DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh); with the peer pub_key and I finally want to store this session key at key 2011/4/19 Michael Sierchio ku...@tenebras.com Addendum - depending on the use of DH (usually using the DH shared secret as a basis for key exchange), the choice of prime is more important than private exponent length. Safe primes or strong primes are warranted. Most systems use small generators (e.g., 2). - M On Mon, Apr 18, 2011 at 7:25 PM, Mike Mohr akih...@gmail.com wrote: You might take a look at RFC 3526: http://tools.ietf.org/html/rfc3526 It is my understanding that the DH exponent can be significantly shorter than the modulus without compromising security. RFC 3526 is from 2003, but I haven't found anything published since then that would make me think its assertions are invalid or outdated. The paranoid tinfoil hat crowd can probably take twice the maximum bit count from section 8 (620x2=1240) and be happy. Mike On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote: Hello, I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) Thanks for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Combining MD5 and SHA-1 to reduce collision probability
Hi all, I'm specially interested on finding a way to uniquely identify rather small data chunks (less than or equal to 128*1024 bytes in size) without using a byte per byte compare. Is there any theoretical proof for a good selection of 2 HASH (computing the results of two different algorithms on the same data) that would annihilate the collision risk ? Unfortunately, I'd guess that the answer could be no, but among the experts on this list, I hope to catch a solid proof, not only a guess. NB: I've mentioned MD5 and SHA-1 in the subject, as they are the most used nowadays, but if this association doesn't fit the need whereas another does, that would be interesting anyway ;-) -- Luc Perthuis, Team Leader, Backup and Restore Technologies luc.perth...@atempo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: some questions about openssl
IMHO openssl is unsuitable for this purpose. Openssl is really good at what it does, don't get me wrong, but using it in a boot loader probably isn't the easiest/smartest idea. What you really want is a subset of PKCS#1 - that is, EMSA-PSS encoding and verification plus RSASP1/RSAVP1. I'm working on some code which happens to implement exactly this feature set using GMP, and it could trivially be ported to some smaller bigint library. I release all my code under GPL3+, and you're welcome to use it as such - but it sounds like you're working on some tivoized system, which is incompatible with GPL3. Mike On Wed, Apr 20, 2011 at 12:39 AM, loody milo...@gmail.com wrote: hi all: My quesitons about openssl are below: 1. I want to take advantage of RSA and SHA in openssl for secure booting. Can they run as standalone program, that means they can run without libc support. 2. I want RSA and sha authentication run in DRAM instead of flash, such that the speed will be faster. Is that possible to fix the link address of openssl? -- Regards, miloody __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Combining MD5 and SHA-1 to reduce collision probability
On 4/20/2011 1:18 AM, Luc Perthuis wrote: Hi all, I'm specially interested on finding a way to uniquely identify rather small data chunks (less than or equal to 128*1024 bytes in size) without using a byte per byte compare. Is there any theoretical proof for a good selection of 2 HASH (computing the results of two different algorithms on the same data) that would annihilate the collision risk ? Simply use a hash for which the probability of a collision (either accidental or malicious) is at least one order of magnitude lower than the probability of your most probable failure mode. IMO, SHA-512 has this characteristic, unless you plan on shielding your hardware from cosmic rays. There is no advantage to using two different algorithms and two huge disadvantages. First, the computation time will be greater. Second, the vulnerability risk is likely greater. It is expected, for example, to be harder to break a single 512-bit hash than to break two 256-bit hashes concurrently. The probability of an accidental collision should be the same -- so why do more work? NB: I've mentioned MD5 and SHA-1 in the subject, as they are the most used nowadays, but if this association doesn't fit the need whereas another does, that would be interesting anyway ;-) If you're willing to go to 288-bits, why not just use 512-bit SHA and truncate to 288 bits? That way, you don't have the known weaknesses of MD5 dragging you down and each bit 'pays its way'. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Conversion of RSA Encrypted message to Base64 format !!!
Hi,
I have done the RSA encryption program. Now I want to convert that encrypted
message to BASE64 message inorder to send the message via socket.
I am trying the following sample code which converts Hello World to Base64
format and *printing in console* ( stdout).
*How can I use the funtion BIO_new_fp(stdout, BIO_NOCLOSE) to print the
value to another character array instead of stdout? If not this,
which Bio_ function I can use so that it will convert to Base64 and put it
in char buffer ?? *
**
#include stdio.h
#include openssl/bio.h
#include openssl/evp.h
int main(int argc, char *argv[])
{
printf(Hello, world\n);
BIO *bio, *b64;
char message[] = Hello World \n;
b64 = BIO_new(BIO_f_base64());
bio = BIO_new_fp(stdout, BIO_NOCLOSE);
//bio = BIO_new_mem_buf(
bio = BIO_push(b64, bio);
BIO_write(bio, message, strlen(message));
BIO_flush(bio);
BIO_free_all(bio);
return 0;
}
Thanks,
Pattabi.
Bug in openssl-0.9.8e
Hello, I have a problem with SSL like in the bug https://bugzilla.redhat.com/show_bug.cgi?id=676384 for the comands sudo -l, getent group, id with my client machine integrated in LDAP. I have apply the patch suggested in the filed bug but I still have a SSL peer reports incorrect Message Authentication Code with those commands. I have checked the certs and everything looks like ok. I'm trying to monitor the ssl connection whit ssldump but I get a Segment Violating: [root@pm1 cacerts]# ssldump -Adn -i eth0 host 192.168.55.105 and port 636 New TCP connection #1: 192.168.55.101(42594) - 192.168.55.105(636) 1 1 0.0250 (0.0250) CS SSLv2 compatible client hello Version 3.1 cipher suites TLS_DH_anon_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 SSL2_CK_RC2 SSL2_CK_RC4 Unknown value 0xff 1 2 0.0271 (0.0021) SC V3.1(3884) Handshake ServerHello Version 3.1 random[32]= 4d ae b2 64 c3 aa 6b 40 60 74 55 b3 6f 66 82 c3 37 86 ae ce fb ec 7c 3b 2a c7 99 1a 68 1a 1c b9 session_id[32]= 05 b5 f6 cc 0e 24 d4 ae bf 5b 8e 88 b2 6e c2 d2 e0 c0 ac f1 0e ee 38 86 09 7d 8a 6a 99 23 5d 59 cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL Certificate CertificateRequest certificate_types rsa_sign certificate_types dss_sign Violación de segmento Have you got any idea wich would be the problem??? Regards, Moisés.
Re: DH session Key length
Sorry I do not see the link between my previous post and your answer. 2011/4/20 Mike Mohr akih...@gmail.com Look, the typical way you'd use the DH shared secret would be to hash it using an appropriate hash function. I personally like using Tiger with AES-192, YMMV. On Tue, Apr 19, 2011 at 3:56 PM, ikuzar razuk...@gmail.com wrote: So, have I to generate a prime with length = 3200 bits ?, ( the corresponding exponent will belong to 3200-bit MODP group ) in order to generate an AES 128 session key ? ( I use 2 as generator ). Here http://tools.ietf.org/html/rfc3526, it is said : The new Advanced Encryption Standard (AES) cipher [AES], which has more strength, needs stronger groups. For the 128-bit AES we need about a 3200-bit group [Orman01]. ..; in this IETF, 6 MODP groups are exposed. 3200-bit is not among this groups... Concretly, what should I write to obtain AES 128 session key? i Wrote something like this ( in command line ): openssl dhparam -outform PEM -out dhParams.pem -2 3200 Then I decode dhParams.pem into internal C struct: dh. Then I call DH_generate_key(DH *dh); , then DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh); with the peer pub_key and I finally want to store this session key at key 2011/4/19 Michael Sierchio ku...@tenebras.com Addendum - depending on the use of DH (usually using the DH shared secret as a basis for key exchange), the choice of prime is more important than private exponent length. Safe primes or strong primes are warranted. Most systems use small generators (e.g., 2). - M On Mon, Apr 18, 2011 at 7:25 PM, Mike Mohr akih...@gmail.com wrote: You might take a look at RFC 3526: http://tools.ietf.org/html/rfc3526 It is my understanding that the DH exponent can be significantly shorter than the modulus without compromising security. RFC 3526 is from 2003, but I haven't found anything published since then that would make me think its assertions are invalid or outdated. The paranoid tinfoil hat crowd can probably take twice the maximum bit count from section 8 (620x2=1240) and be happy. Mike On Mon, Apr 18, 2011 at 8:01 AM, ikuzar razuk...@gmail.com wrote: Hello, I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) Thanks for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Printing a bignumber
Hello, I am having really problems to get a big number printed out in the stdout... This is how it should be (if I got it properly): *BIGNUM *r;* *BIO *out;* * * *out = BIO_new_fp(stdout, BIO_NOCLOSE);* * * *r=BN_new();* * * *BN_rand(r, 2048, -1, 0)* * * *BN_print(out, r);* but when I run it, I just get: OPENSSL_Uplink(60C71000,08): no OPENSSL_Applink Where am I wrong? Thanks in advance, Giuseppe
Re: Printing a bignumber
Solved, i included applink.c 2011/4/20 Giuseppe Barbieri elec...@gmail.com Hello, I am having really problems to get a big number printed out in the stdout... This is how it should be (if I got it properly): *BIGNUM *r;* *BIO *out;* * * *out = BIO_new_fp(stdout, BIO_NOCLOSE);* * * *r=BN_new();* * * *BN_rand(r, 2048, -1, 0)* * * *BN_print(out, r);* but when I run it, I just get: OPENSSL_Uplink(60C71000,08): no OPENSSL_Applink Where am I wrong? Thanks in advance, Giuseppe
RE: Combining MD5 and SHA-1 to reduce collision probability
* Luc Perthuis: Hi all, I'm specially interested on finding a way to uniquely identify rather small data chunks (less than or equal to 128*1024 bytes in size) without using a byte per byte compare. Is there any theoretical proof for a good selection of 2 HASH (computing the results of two different algorithms on the same data) that would annihilate the collision risk ? If the hash is shorter than possible arbitrary input message, there will be a collision risk, because you cannot resolve 2^n possible hashes back to more than 2^n possible messages (even theoretically by using brute force, this is impossible), so among 2^n+1 different messages, at least two of them must have the same 2^n bit hash (actually half because of birthday attack). BTW, what is the use case? Calculating a hash takes much more computing power than a byte-to-byte compare, so I think any hash algorithm is worser than comparing (but of course using hashes can have advantages if the data is on different places or secret). And comparing 128*1024 bytes byte-per-byte is collision free :) Unfortunately, I'd guess that the answer could be no, but among the experts on this list, I hope to catch a solid proof, not only a guess. I think since any n-bit hash guarantees a collision after at least each (!) 2^n different input messages, using a n-bit and a m-bit hash guarantees a collision after at least each 2^(n+m) different input messages. NB: I've mentioned MD5 and SHA-1 in the subject, as they are the most used nowadays, but if this association doesn't fit the need whereas another does, that would be interesting anyway ;-) SHA-1 collision attack need 2^63. Similar to MD5 (I guess ~ 2^64?). SHA-256 should be much stronger, would this be sufficient for your needs? Or SHA-512? oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_Decrypt function- AES cbc 128 bit mode- Input length?
Hi All,
I am trying in vain to find out why the AES decrypt won't work here.
I have found where exactly is the problem and now looking for some
wise-crack to help me solve it.
Here is the code that I tested with(from various posts here):
#include string.h
#include stdio.h
#include stdlib.h
#include openssl/evp.h
int AES_BLOCK_SIZE = 128;
int main(int argc, char **argv)
{
EVP_CIPHER_CTX en;
EVP_CIPHER_CTX de;
EVP_CIPHER_CTX_init(en);
EVP_CIPHER_CTX_init(de);
const EVP_CIPHER *cipher_type;
unsigned char *passkey, *passiv, *plaintxt;
char *plain;
char *plaintext;
unsigned char *ciphertext;
int olen, len;
int i =0;
unsigned char iv[] = { 0x00, 0x01, 0x02, 0x03,
0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b,
0x0c, 0x0d, 0x0e, 0x0f, 0 };
unsigned char key[]= { 0x2b, 0x7e, 0x15, 0x16,
0x28, 0xae, 0xd2, 0xa6,
0xab, 0xf7, 0x15, 0x88,
0x09, 0xcf, 0x4f, 0x3c , 0 };
unsigned char *input = hi this is patrick immling\n'Doctor'.\n'Doctor'
who ?\nPrecisely! 123910!§$$§% !%%$$(/=))?=(#ü++Ü**,.here we go sometimes
it i s difficult but 187! 1$5 78@2 14.TӒ��틪�ձ1z.$�?�U���y;
printf(AES ALGORITHM FOR 128 bit CBC MODE\n);
cipher_type = EVP_aes_128_cbc();
AES_BLOCK_SIZE = 128;
passkey = key;
passiv = iv;
plain = input;
printf(Initializing AES ALGORITHM FOR CBC MODE..\n);
EVP_EncryptInit_ex(en, cipher_type, NULL, passkey, passiv);
EVP_DecryptInit_ex(de, cipher_type, NULL, passkey, passiv);
olen = len = strlen(input)+1;
printf(len value before aes_encrypt \%d\\n, len);
int c_len = len + AES_BLOCK_SIZE - 1;
int f_len = 0;
ciphertext = (unsigned char *)malloc(c_len);
if(!EVP_EncryptInit_ex(en, NULL, NULL, NULL, NULL)){
printf(ERROR in EVP_EncryptInit_ex \n);
return NULL;
}
if(!EVP_EncryptUpdate(en, ciphertext, c_len, plain, len)){
printf(ERROR in EVP_EncryptUpdate \n);
return NULL;
}
printf(len value after update \%d\\n, len);
// printf(size of ciphertext after update \%d\\n,
sizeof(ciphertext));
printf(strlen value of ciphertext after update \%d\\n,
strlen(ciphertext));
if(!EVP_EncryptFinal_ex(en, ciphertext+c_len, f_len)){
printf(ERROR in EVP_EncryptFinal_ex \n);
return NULL;
}
printf(len value after final \%d\\n, len);
printf(strlen value of ciphertext after final \%d\\n,
strlen(ciphertext));
EVP_CIPHER_CTX_cleanup(en);
len = c_len + f_len;
printf(len value after aes_encrypt \%d\\n, len);
//HERE IS THE PROBLEM: IF I USE len= strlen(ciphertext) I GET ERROR
//len = strlen(ciphertext);
printf(strlen value of ciphertext after aes_encrypt \%d\\n,
len);
int p_len = len;
f_len = 0;
plaintext = (unsigned char *)malloc(p_len);
// memset(plaintext,0,sizeof(plaintext));
if(!EVP_DecryptInit_ex(de, NULL, NULL, NULL, NULL)){
printf(ERROR in EVP_DecryptInit_ex \n);
return NULL;
}
EVP_CIPHER_CTX_set_padding(de, 0);
if(!EVP_DecryptUpdate(de, plaintext, p_len, ciphertext, len)){
printf(ERROR in EVP_DecryptUpdate\n);
return NULL;
}
printf(len value after decrypt update \%d\\n, len);
if(!EVP_DecryptFinal_ex(de, plaintext+p_len, f_len)){
printf(ERROR in EVP_DecryptFinal_ex\n);
ERR_print_errors_fp(stderr);
return NULL;
}
EVP_CIPHER_CTX_cleanup(de);
len = p_len + f_len;
printf(Decrypted value = %s\n, plaintext);
printf(len value after aes_decrypt \%d\\n, len);
if (strncmp(plaintext, input, olen))
printf(FAIL: enc/dec failed for \%s\\n, input);
else
printf(OK: enc/dec ok for \%s\\n, plaintext); // \%s\\n
printf(\n);
free(ciphertext);
free(plaintext);
return 0;
}
What I dont understand:
What should I feed as the len parameter for the openSSL EVP Decrypt
routines?
what is this magic len = c_len+ f_len?
How should I get this in case I am given just the cipher with the key and
the iv? This should be always possible right? I know strlen is a bad
parametr especially for binary as the ciphertext input to EVP Decrypt is
binary: so how should I get this?
I can already see that if I use len= strlen(ciphertext) gives me a wrong
answer and sizeof parameter is also not
Re: Conversion of RSA Encrypted message to Base64 format !!!
On 20 Apr 2011, at 3:01 AM, pattabi raman wrote: How can I use the funtion BIO_new_fp(stdout, BIO_NOCLOSE) to print the value to another character array instead of stdout? If not this, which Bio_ function I can use so that it will convert to Base64 and put it in char buffer ?? I think you want to use a memory BIO, e.g. BIO_new(BIO_s_mem()). If your C library has the funopen() call, you could use that to write to a memory buffer using BIO_new_fp(), but that seems silly. :) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
PKCS12 - Why Encrypted?
I'm pretty new to this PKI stuff, but I'm very confused about why pkcs12 files are encrypted. As I understand it, a basic p12 file contains within it two things: (1) A private key (private.pem in my case, an RSA key created with genrsa) (2) An x509 certificate (cert.pem in my case, created with req -new -x509 -key private.pem etc...) When you create the x509 certificate it isn't encrypted, because all it stores inside of it is the public key which is generated from the given private.pem; and that's not sensitive data. As far as I can see, there aren't even any options in the openssl req sub-utility to encrypt the cert created by -new -x509. Now, if I understand correctly, when you take cert.pem and private.pem and store them together into a p12 file, the pkcs12 sub-utility defaults to encrypting the p12 file as a whole, even beyond the fact that the internal private key is already encrypted, and despite the fact that (I think) the certificate doesn't need to be encrypted. I'm guessing I'm probably missing something here. It's not just that I think encrypting the cert would be silly and paranoid, it's that I don't understand why it needs to be encrypted in principle. Many thanks in advance for any help in clearing up a newbie's confusion, -Patrick P.S. If there are any de facto standard books to read on the subjecst of RSA and PKI, I would be curious to hear a tip. I'm not necessarily just interested in learning how to use these technologies from a user-end perspective. I'm pretty solid with mathematics, so I would be curious to learn about the theory of the implementation details as well. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH session Key length
2011/4/19 Dave Thompson dthomp...@prinpay.com From: owner-openssl-us...@openssl.org On Behalf Of ikuzar Sent: Monday, 18 April, 2011 11:01 I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) The size of both private (x) and public (y) values in DH is the same as the size of the prime P or very nearly. If the parameters were generated with openssl commandline 'dhparam' the default size of P was 512 bits, which is probably not secure. If P = 512 bits is not secure so shared key ( 512 bits ) generated with this P is not secured. Necessarily, shared key with 128 bits is not secured, and then AES 128 is not secured ? I am confused... Is there any way to understand in 2, 3 words how to generate a shared key with 128 bits length from Dh params ? For example g = 2, P = 128 = shared key length = 128 Thanks, Ikuzar (I know factoring thus RSA up to 700-something is broken; I haven't heard of results for discrete-log thus DH and DSA, but on my limited knowledge of number theory I think it should be about the same.) (Good) asymmetric algorithms need more bits for comparable security than (good) symmetric ones. Experts do not agree on an exact correspondence, but in (very) rough terms elliptic-curve algs are about 2x symmetric, and traditional asymmetric (RSA, DH, DSA, etc) are in the vicinity of 20x. NIST Special Publication 800-57 available under csrc.nist.gov seems to be a good reflection of reasonably current thinking. There is or at least was a few years ago an independent site with the consensus of leading academic crypto researchers, but I can't find it now. (If you don't know it, NIST = National Institute for Science and Technology is a part of the US government Department of Commerce; it was formerly NBS National Bureau of Standards.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH session Key length
Ikuzar, I'm not sure what software you're writing. Please understand that I'm not trying to be mean spirited when I say this, but if you don't already know the difference between symmetric vs public-key crypto then you should not be writing this type of code. Stop doing it until you have a firm grasp on the basic concepts. Any code you write now is nearly guaranteed to be incorrect. You should take a few months to read the book I linked you to earlier and really understand the basic concepts. You will get much better support from this mailing list once you do. Mike On Wed, Apr 20, 2011 at 3:06 PM, ikuzar razuk...@gmail.com wrote: 2011/4/19 Dave Thompson dthomp...@prinpay.com From: owner-openssl-us...@openssl.org On Behalf Of ikuzar Sent: Monday, 18 April, 2011 11:01 I 'd like to know the length of DH session key generated by DH_compute_key(unsigned char *key, BIGNUM *pub_key, DH *dh) . Here : http://www.openssl.org/docs/crypto/DH_generate_key.html It is said that key must point to DH_size(dh) bytes of memory. is 128 bits the default length ? how can I adjust this length according the symetric-key algorithm I use ( AES128/ICM) The size of both private (x) and public (y) values in DH is the same as the size of the prime P or very nearly. If the parameters were generated with openssl commandline 'dhparam' the default size of P was 512 bits, which is probably not secure. If P = 512 bits is not secure so shared key ( 512 bits ) generated with this P is not secured. Necessarily, shared key with 128 bits is not secured, and then AES 128 is not secured ? I am confused... Is there any way to understand in 2, 3 words how to generate a shared key with 128 bits length from Dh params ? For example g = 2, P = 128 = shared key length = 128 Thanks, Ikuzar (I know factoring thus RSA up to 700-something is broken; I haven't heard of results for discrete-log thus DH and DSA, but on my limited knowledge of number theory I think it should be about the same.) (Good) asymmetric algorithms need more bits for comparable security than (good) symmetric ones. Experts do not agree on an exact correspondence, but in (very) rough terms elliptic-curve algs are about 2x symmetric, and traditional asymmetric (RSA, DH, DSA, etc) are in the vicinity of 20x. NIST Special Publication 800-57 available under csrc.nist.gov seems to be a good reflection of reasonably current thinking. There is or at least was a few years ago an independent site with the consensus of leading academic crypto researchers, but I can't find it now. (If you don't know it, NIST = National Institute for Science and Technology is a part of the US government Department of Commerce; it was formerly NBS National Bureau of Standards.) __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS12 - Why Encrypted?
PKCS doc., including PKCS12 http://www.rsa.com/rsalabs/node.asp?id=2124 http://www.rsa.com/rsalabs/node.asp?id=2124 On Wed, Apr 20, 2011 at 5:03 PM, Patrick Rutkowski rutsk...@gmail.comwrote: I'm pretty new to this PKI stuff, but I'm very confused about why pkcs12 files are encrypted. As I understand it, a basic p12 file contains within it two things: (1) A private key (private.pem in my case, an RSA key created with genrsa) (2) An x509 certificate (cert.pem in my case, created with req -new -x509 -key private.pem etc...) When you create the x509 certificate it isn't encrypted, because all it stores inside of it is the public key which is generated from the given private.pem; and that's not sensitive data. As far as I can see, there aren't even any options in the openssl req sub-utility to encrypt the cert created by -new -x509. Now, if I understand correctly, when you take cert.pem and private.pem and store them together into a p12 file, the pkcs12 sub-utility defaults to encrypting the p12 file as a whole, even beyond the fact that the internal private key is already encrypted, and despite the fact that (I think) the certificate doesn't need to be encrypted. I'm guessing I'm probably missing something here. It's not just that I think encrypting the cert would be silly and paranoid, it's that I don't understand why it needs to be encrypted in principle. Many thanks in advance for any help in clearing up a newbie's confusion, -Patrick P.S. If there are any de facto standard books to read on the subjecst of RSA and PKI, I would be curious to hear a tip. I'm not necessarily just interested in learning how to use these technologies from a user-end perspective. I'm pretty solid with mathematics, so I would be curious to learn about the theory of the implementation details as well. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl dgst using ecdsa-with-SHA384
Hi all, I'm having a problem using ecdsa with SHA 384 when creating a message digest. I will admit I'm not too familiar with openssl and digests, but I have code that works using -ecdsa-with-SHA1. I need to change that to use ecdsa-with-SHA384. I looked at the release notes to see that this should be supported with openssl version 1.1.0 and later, but I've tried that version as well as the latest 1.0.0d, and get a unknown option '-ecdsa-with-SHA384' The command I use is: /usr/local/openssl/bin/openssl dgst -ecdsa-with-SHA384 -binary -out signersCertDgst.tmp x509/public.pem This same command works when using -ecdsa-with-SHA1 I've looked at the openssl source and it appears to support the -ecdsa-with-SHA384, but it's not straight forward to trace it through the source code. Has anyone gotten this to work? Am I doing something wrong? I assume -sha384 is different than -ecdsa-with-SHA384. Any help would be appreciated!
