Re: Convert symmetrically encrypted content to base64
Hi Bjoern,
please see my comments below:
(rather Qt and memory related)
On Thu, Aug 23, 2012 at 03:12:55PM +0200, Bjoern Schiessle wrote:
QMapQString, QString Encryption::key2pem(RSA *rsa, QString password)
{
QMapQString, QString keypair;
BUF_MEM *bptr;
BIO *pubBio = BIO_new(BIO_s_mem());
BIO *privBio = BIO_new(BIO_s_mem());
PEM_write_bio_RSA_PUBKEY(pubBio, rsa);
PEM_write_bio_RSAPrivateKey(privBio, rsa, EVP_aes_128_cfb(),NULL,
0, 0, password.toLocal8Bit().data());
The following block can be simplified:
BIO_get_mem_ptr(pubBio, bptr);
char *pubKey = (char *)malloc(bptr-length+1);
memcpy(pubKey, bptr-data, bptr-length);
pubKey[bptr-length] = 0;
BIO_get_mem_ptr(pubBio, bptr);
keypair[publickey] = QString::fromAscii(bptr-data, bptr-length);
BIO_get_mem_ptr(privBio, bptr);
char *privKey = (char *)malloc(bptr-length+1);
memcpy(privKey, bptr-data, bptr-length);
privKey[bptr-length] = 0;
BIO_get_mem_ptr(privBio, bptr);
keypair[privatekey] = QString::fromAscii(bptr-data, bptr-length);
keypair[privatekey] = QString(privKey);
keypair[publickey] = QString(pubKey);
/* this would be required in your code */
free(privKey);
free(pubKey);
Cheers
Christian
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Entropy for OpenSSL
Ping! Anybody? Charles -Original Message- Sent: Wednesday, August 22, 2012 10:07 AM To: openssl-users@openssl.org Subject: Entropy for OpenSSL I'm looking at https://groups.google.com/forum/?fromgroups#!topic/mailing.openssl.users/j8O bkLf6xgs Do I interpret it correctly as saying that assuming I do not have some clever source of entropy of my own, that I should just do nothing and let OpenSSL do what it decides is best? In other words, that I should NOT call app_RAND_load_file() (as the current source for s_client does) nor RAND_screen() (as O'Reilly sort-of advises)? Thanks, Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS error on Apache httpd v2.4.3, OpenSSL 1.0.1c and fips-2.0.1
Thanks, Cassie Ldd shows Apache httpd uses Redhat (v6.x)'s built in /lib64/libcrypto.so/a not my OpenSSL's /usr/local/ssl/lib/libcrypto.so. I got to fix that problem first. Thanks. Ryan Jiang -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Helms, Cassie Sent: Thursday, August 23, 2012 3:26 PM To: openssl-users@openssl.org Subject: RE: FIPS error on Apache httpd v2.4.3, OpenSSL 1.0.1c and fips-2.0.1 Ryan, A previous thread, fingerprint does not match on FIPS_mode_set when FIPS + openssl is dynamically linked into build, might be of some use to you. As a first step, you may want to use ldd on your executable to make sure libcrypto.so/a points to 1.0.1c and not some other version of openssl. The thread has more information on this issue. Cassie __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org This message (including any attachments) is intended solely for the specific individual(s) or entity(ies) named above, and may contain legally privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, by other than the intended recipient, is strictly prohibited. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssh error - Solaris 10 SPARC Platform
Hi, I have a Sun Solaris 10 Server that I have upgraded the Openssh version 5.3p1 to version 6.0p1. I have upgraded openssl from version 0.9.81 to version 1.0.1c. When I check the ssh log file I see the error. Please can you provide some help how to resolve this issue ? == [ Aug 23 16:19:03 Executing start method (/lib/svc/method/sshd start) ] starting /usr/local/sbin/sshd... OpenSSL version mismatch. Built against 1000103f, you have 10af /lib/svc/method/sshd: Error 255 starting /usr/local/sbin/sshd... bailing. [ Aug 23 16:19:03 Method start exited with status 255 ] Thanks. Roberto Ballan email: roberto.bal...@macys.com
Re: OpenSSL on beagleboard
On Fri, Aug 24, 2012 at 2:18 AM, Jeffrey Walton noloa...@gmail.com wrote: On Thu, Aug 23, 2012 at 9:06 PM, Paulo Roberto bad_boy_...@hotmail.com wrote: Hello, I am using the package libssl-dev on ubuntu in my beagleboard xm, and I have to run two C algorithms using the openSSL library.. Although I can't compile using the command: gcc test.c -lssl -o test. It seems the compiler isn't recognizing the -lssl command. You really need to show the error, I doubt it is not recognizing it. Does someone know how to solve this? Do I have to set some path, or something like that? You might do, use -L for this. You specify linker commands (such as libraries) at the very end of the compiler drive command. From the g++ man pages (around line 25): ...the placement of the -l option is significant. Significant relative to .o and other libraries, not to the output file, so this should make no difference. gcc test.c -o test -lssl You might also want to add -Wl,-Bstatic unless you want to do the shared object thing. Jeff __ 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
RE: Entropy for OpenSSL
OpenSSL will try to use random sources available for the OS, so supplying your own additional randomization is usually not required. You can call RAND_status() to determine if the library was successful getting enough random data that it decides it can start providing random numbers. It will return a 1 if it was, or a 0 if more random data is needed. That being said, the randomization algorithm used by OpenSSL is designed so that the randomness of the numbers returned will not be reduced by submitting additional random or pseudo-random data using the RAND_add() call. I always make it a habit to write my code so it saves a file of random data when OpenSSL is closed, and loads that same random data file the next time it is opened. (See the functions RAND_write_file() and RAND_load_file().) That way I know that OpenSSL will start in a well-randomized state, and any additional randomization initialization done by the library can only make things better. If you have access to other information that is pseudo-random, such as network packets, it might not be a bad idea to call RAND_add() on that data as well. RAND_screen() is specific to Windows, and uses a snapshot of the desktop to use as random data. It won't hurt to call this if you can, but is not particularly effective. There are also some situations, such as calling OpenSSL from a Windows service, where the desktop is static or not available. That is why OpenSSL no longer relies on it. Brant -Original Message- Sent: Wednesday, August 22, 2012 10:07 AM To: openssl-users@openssl.org Subject: Entropy for OpenSSL I'm looking at https://groups.google.com/forum/?fromgroups#!topic/mailing.openssl.users/j8O bkLf6xgs Do I interpret it correctly as saying that assuming I do not have some clever source of entropy of my own, that I should just do nothing and let OpenSSL do what it decides is best? In other words, that I should NOT call app_RAND_load_file() (as the current source for s_client does) nor RAND_screen() (as O'Reilly sort-of advises)? Thanks, Charles __ 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
DH exchange socket BIOs
(sorry if this mail arrives twice. I send it first without being subscribed to this list by accident) Hi all I try to implement a DH exchange using socket BIOs. Here is what I do: On the server - I initialize a DH structure with DH_new - I generate the parameters using DH_generate_parameters(prime_len,g,NULL,NULL) with prime_len=512 - I generate the keys using DH_generate_key(dh) Now I need to send p,g, and the server's public key to the client. In order to do that I convert each of those three values to hex. This is the example for p: int size = DH_size(dh); char* prime = (char*) malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); prime = BN_bn2hex(dh-p); afterwards I open a socket BIO that allows a client to connect: bio = BIO_new_accept(port); Now, when a client connects, I write those three values to the BIO. Example for p: BIO_do_accept(bio); cbio = BIO_pop(bio); BIO_write(cbio,prime,size); Ok, lets move the client. The client connects successfully to the server and reads the three values from the BIO: prime = (char*)malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); BIO_read(bio,prime,size); If I print out prime on the client using printf I see that this is exactly the stream of bytes that have been sent by the server. But if I write this value back into a DH structure it changes: DH *dh = DH_new(); BN_hex2bn((dh-p),prime); If I check the value now with BN_print, it is a shorter value! It is just about half the length of the original p and I have no idea why. What is it that I miss here? Any hints would be appreciated Regards Carolin
DH exchange socket BIOs
Hi all I try to implement a DH exchange using socket BIOs. Here is what I do: On the server - I initialize a DH structure with DH_new - I generate the parameters using DH_generate_parameters(prime_len,g,NULL,NULL) with prime_len=512 - I generate the keys using DH_generate_key(dh) Now I need to send p,g, and the server's public key to the client. In order to do that I convert each of those three values to hex. This is the example for p: int size = DH_size(dh); char* prime = (char*) malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); prime = BN_bn2hex(dh-p); afterwards I open a socket BIO that allows a client to connect: bio = BIO_new_accept(port); Now, when a client connects, I write those three values to the BIO. Example for p: BIO_do_accept(bio); cbio = BIO_pop(bio); BIO_write(cbio,prime,size); Ok, lets move the client. The client connects successfully to the server and reads the three values from the BIO: prime = (char*)malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); BIO_read(bio,prime,size); If I print out prime on the client using printf I see that this is exactly the stream of bytes that have been sent by the server. But if I write this value back into a DH structure it changes: DH *dh = DH_new(); BN_hex2bn((dh-p),prime); If I check the value now with BN_print, it is a shorter value! It is just about half the length of the original p and I have no idea why. What is it that I miss here? Any hints would be appreciated Regards Carolin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH exchange socket BIOs
Hi Carolin, It is just about half the length of the ... [very] Quick response : Hex value is twice the lengh of binary data : Have you checked the value of 'size' arg ? Not sure this helps ... Le 24/08/2012 16:38, Carolin Latze a écrit : (sorry if this mail arrives twice. I send it first without being subscribed to this list by accident) Hi all I try to implement a DH exchange using socket BIOs. Here is what I do: On the server - I initialize a DH structure with DH_new - I generate the parameters using DH_generate_parameters(prime_len,g,NULL,NULL) with prime_len=512 - I generate the keys using DH_generate_key(dh) Now I need to send p,g, and the server's public key to the client. In order to do that I convert each of those three values to hex. This is the example for p: int size = DH_size(dh); char* prime = (char*) malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); prime = BN_bn2hex(dh-p); afterwards I open a socket BIO that allows a client to connect: bio = BIO_new_accept(port); Now, when a client connects, I write those three values to the BIO. Example for p: BIO_do_accept(bio); cbio = BIO_pop(bio); BIO_write(cbio,prime,size); Ok, lets move the client. The client connects successfully to the server and reads the three values from the BIO: prime = (char*)malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); BIO_read(bio,prime,size); If I print out prime on the client using printf I see that this is exactly the stream of bytes that have been sent by the server. But if I write this value back into a DH structure it changes: DH *dh = DH_new(); BN_hex2bn((dh-p),prime); If I check the value now with BN_print, it is a shorter value! It is just about half the length of the original p and I have no idea why. What is it that I miss here? Any hints would be appreciated Regards Carolin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH exchange socket BIOs
Yeah size is the same on both sides :( - Reply message - From: Michel msa...@paybox.com To: openssl-users@openssl.org Subject: DH exchange socket BIOs Date: Fri, Aug 24, 2012 5:47 pm Hi Carolin, It is just about half the length of the ... [very] Quick response : Hex value is twice the lengh of binary data : Have you checked the value of 'size' arg ? Not sure this helps ... Le 24/08/2012 16:38, Carolin Latze a écrit : (sorry if this mail arrives twice. I send it first without being subscribed to this list by accident) Hi all I try to implement a DH exchange using socket BIOs. Here is what I do: On the server - I initialize a DH structure with DH_new - I generate the parameters using DH_generate_parameters(prime_len,g,NULL,NULL) with prime_len=512 - I generate the keys using DH_generate_key(dh) Now I need to send p,g, and the server's public key to the client. In order to do that I convert each of those three values to hex. This is the example for p: int size = DH_size(dh); char* prime = (char*) malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); prime = BN_bn2hex(dh-p); afterwards I open a socket BIO that allows a client to connect: bio = BIO_new_accept(port); Now, when a client connects, I write those three values to the BIO. Example for p: BIO_do_accept(bio); cbio = BIO_pop(bio); BIO_write(cbio,prime,size); Ok, lets move the client. The client connects successfully to the server and reads the three values from the BIO: prime = (char*)malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); BIO_read(bio,prime,size); If I print out prime on the client using printf I see that this is exactly the stream of bytes that have been sent by the server. But if I write this value back into a DH structure it changes: DH *dh = DH_new(); BN_hex2bn((dh-p),prime); If I check the value now with BN_print, it is a shorter value! It is just about half the length of the original p and I have no idea why. What is it that I miss here? Any hints would be appreciated Regards Carolin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DH exchange socket BIOs
Uh maybe this is the point: how do you init the size of a dh struct correctly? I just set it like size=64 - Reply message - From: Michel msa...@paybox.com To: openssl-users@openssl.org Subject: DH exchange socket BIOs Date: Fri, Aug 24, 2012 5:47 pm Hi Carolin, It is just about half the length of the ... [very] Quick response : Hex value is twice the lengh of binary data : Have you checked the value of 'size' arg ? Not sure this helps ... Le 24/08/2012 16:38, Carolin Latze a écrit : (sorry if this mail arrives twice. I send it first without being subscribed to this list by accident) Hi all I try to implement a DH exchange using socket BIOs. Here is what I do: On the server - I initialize a DH structure with DH_new - I generate the parameters using DH_generate_parameters(prime_len,g,NULL,NULL) with prime_len=512 - I generate the keys using DH_generate_key(dh) Now I need to send p,g, and the server's public key to the client. In order to do that I convert each of those three values to hex. This is the example for p: int size = DH_size(dh); char* prime = (char*) malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); prime = BN_bn2hex(dh-p); afterwards I open a socket BIO that allows a client to connect: bio = BIO_new_accept(port); Now, when a client connects, I write those three values to the BIO. Example for p: BIO_do_accept(bio); cbio = BIO_pop(bio); BIO_write(cbio,prime,size); Ok, lets move the client. The client connects successfully to the server and reads the three values from the BIO: prime = (char*)malloc(size*sizeof(char)); memset(prime,0,size*sizeof(char)); BIO_read(bio,prime,size); If I print out prime on the client using printf I see that this is exactly the stream of bytes that have been sent by the server. But if I write this value back into a DH structure it changes: DH *dh = DH_new(); BN_hex2bn((dh-p),prime); If I check the value now with BN_print, it is a shorter value! It is just about half the length of the original p and I have no idea why. What is it that I miss here? Any hints would be appreciated Regards Carolin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Convert symmetrically encrypted content to base64
Hi Christian,
On Fri, 24 Aug 2012 08:11:25 +0200 Christian Hohnstaedt wrote:
please see my comments below:
(rather Qt and memory related)
Thank you for your feedback. Now I'm trying the implement the function
which does exactly the opposite: Take the public and private key in
the PEM format from the server and import it in a RSA structure:
void Encryption::pem2key(QString publickey, QString privatekey, QString
password)
{
BIO *pubBio = BIO_new_mem_buf(publickey.toLocal8Bit().data(),
strlen(publickey.toLocal8Bit().data()));
BIO *privBio = BIO_new_mem_buf(privatekey.toLocal8Bit().data(),
strlen(privatekey.toLocal8Bit().data()));
RSA *rsa = RSA_new();
PEM_read_bio_RSAPublicKey(pubBio, rsa, 0, NULL);
PEM_read_bio_RSAPrivateKey(privBio, rsa, 0, password.toLocal8Bit().data());
Keymanager::Instance()-setRSAkey(rsa);
BIO_free_all(pubBio);
BIO_free_all(privBio);
}
The program compiles and run without a problem. But if I call the
key2pem() function with the newly imported RSA key. I get two quite
short keys back (only half a line of data). So something seems to go
wrong during import of the PEM encoded keys.
Any idea what I'm doing wrong in the pem2key() function?
Thanks!
Björn
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Entropy for OpenSSL
Thanks. RAND_status() is returning a 1 so I guess I am good for now. I put in an error message if it fails to return a 1. I will keep an eye on this problem going forward. The product is designed to run as a Windows Service but I am currently testing in console mode. I will specifically watch what happens when I run as a service. (PITA to test as a Service and I am not going to do it today.) Thanks again for your help. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomsen, Brant Sent: Friday, August 24, 2012 10:30 AM To: openssl-users@openssl.org Subject: RE: Entropy for OpenSSL OpenSSL will try to use random sources available for the OS, so supplying your own additional randomization is usually not required. You can call RAND_status() to determine if the library was successful getting enough random data that it decides it can start providing random numbers. It will return a 1 if it was, or a 0 if more random data is needed. That being said, the randomization algorithm used by OpenSSL is designed so that the randomness of the numbers returned will not be reduced by submitting additional random or pseudo-random data using the RAND_add() call. I always make it a habit to write my code so it saves a file of random data when OpenSSL is closed, and loads that same random data file the next time it is opened. (See the functions RAND_write_file() and RAND_load_file().) That way I know that OpenSSL will start in a well-randomized state, and any additional randomization initialization done by the library can only make things better. If you have access to other information that is pseudo-random, such as network packets, it might not be a bad idea to call RAND_add() on that data as well. RAND_screen() is specific to Windows, and uses a snapshot of the desktop to use as random data. It won't hurt to call this if you can, but is not particularly effective. There are also some situations, such as calling OpenSSL from a Windows service, where the desktop is static or not available. That is why OpenSSL no longer relies on it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Convert symmetrically encrypted content to base64
From: owner-openssl-us...@openssl.org On Behalf Of Bjoern Schiessle
Sent: Friday, 24 August, 2012 12:14
snip Now I'm trying the implement the function
which does exactly the opposite: Take the public and private key in
the PEM format from the server and import it in a RSA structure:
Note OpenSSL's RSA privatekey *includes* publickey.
RSA publickey is n,e and naive privatekey is n,d,
but OpenSSL privatekey is CRT form with n,d,e,p,q + more.
There is no need to transmit the publickey separately,
(Not for DH or ECDH, though.)
void Encryption::pem2key(QString publickey, QString
privatekey, QString password)
{
BIO *pubBio =
BIO_new_mem_buf(publickey.toLocal8Bit().data(),
strlen(publickey.toLocal8Bit().data()));
BIO *privBio =
BIO_new_mem_buf(privatekey.toLocal8Bit().data(),
strlen(privatekey.toLocal8Bit().data()));
Tiny aside: BIO_new_mem_buf will do the strlen() for you
if you pass -1 for length. Just a convenience.
RSA *rsa = RSA_new();
PEM_read_bio_RSAPublicKey(pubBio, rsa, 0, NULL);
PEM_read_bio_RSAPrivateKey(privBio, rsa, 0,
password.toLocal8Bit().data());
Keymanager::Instance()-setRSAkey(rsa);
BIO_free_all(pubBio);
BIO_free_all(privBio);
}
The program compiles and run without a problem. But if I call the
key2pem() function with the newly imported RSA key. I get two quite
short keys back (only half a line of data). So something seems to go
wrong during import of the PEM encoded keys.
Any idea what I'm doing wrong in the pem2key() function?
If PEM_read_* returns null (or nearly any other OpenSSL
routine returns a failure indication), look at the error queue.
http://www.openssl.org/support/faq.html#PROG6
and #PROG7 also if you don't get readable error.
If they didn't, look very carefully at your PEM data.
Commandline can do this: openssl asn1parse -in myprivkey.pem
and/or: openssal rsa -in myprivkey.pem -text
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
