Re: Reworking OpenSSL code from using files to reading keys from memory
In similar way, you could generate your own BIO by BIO_new_mem_buf((void*) cacert, len). Then call PEM_X509_INFO_read_bio, then e.g. for x509, use X509_STORE_add_cert for each one in sk_x509_INFO_num(). Hope this helps Huaqing On Wed, Jan 11, 2012 at 2:47 PM, Wojciech Kocjan wrote: > Hello, > > I am working on reworking existing code that uses several OpenSSL APIs > from using files to store keys, certificates and CAs to passing this > directly from memory (so that it can be retrieved from memory, read > from encrypted storage among other things). > > This is my first post here, so if this is not the correct group and/or > anything below seems obvious/completely incorrect, please feel free to > correct me. > > Our code currently uses the following APIs: > > - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file > > This part seems easier. From what I understand, I can use BIO_s_mem > and pass it key/certificate data from memory. I could then use PEM to > get EVP_PKEY or X509. > > Then I could just invoke SSL_CTX_use_certificate() and > SSL_CTX_use_PrivateKey() directly. > > In practice it may be a bit more complex, but at least I know the solution. > > - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis > > This part is the harder one. I was not able to find any APIs to do this. > > Another alternative I was wondering about is whether I can provide > another way for OpenSSL to access the keys - i.e. so that I can tell > that filename is something like mystorage://key1.pem and OpenSSL would > use my BIO (or create BIO_s_mem and preload it with data) instead of > BIO_s_file. > > Thanks. > > -- > WK > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > -- Thank you. Best Regards, Michael(Huaqing) Wang
Reworking OpenSSL code from using files to reading keys from memory
Hello, I am working on reworking existing code that uses several OpenSSL APIs from using files to store keys, certificates and CAs to passing this directly from memory (so that it can be retrieved from memory, read from encrypted storage among other things). This is my first post here, so if this is not the correct group and/or anything below seems obvious/completely incorrect, please feel free to correct me. Our code currently uses the following APIs: - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file This part seems easier. From what I understand, I can use BIO_s_mem and pass it key/certificate data from memory. I could then use PEM to get EVP_PKEY or X509. Then I could just invoke SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey() directly. In practice it may be a bit more complex, but at least I know the solution. - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis This part is the harder one. I was not able to find any APIs to do this. Another alternative I was wondering about is whether I can provide another way for OpenSSL to access the keys - i.e. so that I can tell that filename is something like mystorage://key1.pem and OpenSSL would use my BIO (or create BIO_s_mem and preload it with data) instead of BIO_s_file. Thanks. -- WK __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
AES-Assembler for Powerpc
Hi all,
I tried using the AES-assembler code for my PowerPC EABI, but everytime I start
"speed aes" my OS crashes. The 32Bit OS is a custom one.
The first problem was the usage of r13. On Page 3 of the PowerPC EABI spec [1],
the r13 register is described as a dedicated register.
So the usage of such a register is delicate.
I could not use it because it is forbidden in our startup code.
But at Line 101 of "crypto/aes/asm/aes-ppc.pl" I found a workaround for the 64
bit case, which replaces r13 with r0.
# stay away from TLS pointer
if ($SIZE_T==8) { die if ($t1 ne "r13"); $t1="r0"; }
else{ die if ($Tbl3 ne "r2"); $Tbl3=$t0; $t0="r0"; }
So in the aes-ppc Perl source I replaced r13 with r0 at line 77, which made the
line 538
lwz $t1,4($key)
execute smoothly.
I do not think it compromises the security since its just using a different
register.
The second and much more delicate problem was the "LAES_Te" symbol: why do we
need this piece of code? Would it be safe to leave it aside? I'm asking because
this code (in my case) overwrites r3, therefore leaving me without access to
the first argument of the whole function. Because the value of the link
register is saved in r3, the "out" argument will point to the .text section,
and thus the whole code will crash if the MMU prohibits accesses to this
section.
Sincerely yours
Marius Peschke
[1]
http://www.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF77852569970071B0D6/$file/eabi_app.pdf
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
