Re: Searching the "true" about multithreading
faturita writes: [...] > This is all very basic, and it is working but I am aware of the "OpenSSL > multithreading (or not so) things" and I would like to know if this basic > stuff > needs some form of synchronization Not quite an answer to your question, but when faced with a similar problem about a year ago, we rewrote our code to use boost asio, and were very pleased with the results. It handled the SSL and helped us get rid of our very resource-hungry one-thread-per-connection model, without tons of changes outside of the I/O layer. Hope this is helpful, Scott. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Padding mode for RSA_private_decrypt()...
Hi, You simply can't guess the padding mode if you don't know it in advance. Imagine the security consequences if this was possible : it would mean that an attacker can have information about the clear text without having access to the private key!! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr barcaroller wrote: How can I tell what the padding mode was before I attempt to decrypt data. For example, when I use RSA_private_decrypt(encsize, encdata, decdata, privkey, RSA_PKCS1_PADDING) I sometimes (but not always) get the following error: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02 __ 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
Memory leaks...
I'm getting some memory leaks when I use OpenSSL. I was not able to get rid of these leaks, even when I use EVP_cleanup() and ERR_free_strings() at the end of my program. Memory Leak 1. PEM_read_PrivateKey() = EVP_PKEY* key = PEM_read_PrivateKey(fp, NULL, 0, NULL); ... EVP_PKEY_free(key); Valgrind reports: ==27769== 24 bytes in 1 blocks are still reachable in loss record 2 of 20 ==27769==at 0x4A05809: malloc (vg_replace_malloc.c:149) ==27769==by 0x3C3C6DAD41: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C65B565: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C65B98A: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C66F9B3: RSA_new_method (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C66F33C: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C692EA4: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C696004: ASN1_item_ex_d2i (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C6960F3: ASN1_item_d2i (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C68FC0C: d2i_PrivateKey (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C6A10B9: PEM_read_bio_PrivateKey (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C6A1300: PEM_read_PrivateKey (in /lib64/libcrypto.so.0.9.8e) Memory Leak 2. SSL_library_init() = Valgrind reports: ==27769== 24 bytes in 1 blocks are still reachable in loss record 6 of 20 ==27769==at 0x4A05809: malloc (vg_replace_malloc.c:149) ==27769==by 0x3C3C6DAD41: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C65B565: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C65BB3B: (within /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3C6BFBFA: COMP_zlib (in /lib64/libcrypto.so.0.9.8e) ==27769==by 0x3C3CA31D7F: (within /lib64/libssl.so.0.9.8e) ==27769==by 0x3C3CA31F48: SSL_COMP_get_compression_methods (in /lib64/libssl.so.0.9.8e) ==27769==by 0x3C3CA37784: SSL_library_init (in /lib64/libssl.so.0.9.8e) Memory Leak 3. HMAC_Init() == HMAC_CTX hm; HMAC_Init(&hm, ...); HMAC_Update(&hm, ...); HMAC_Final(&hm, ...); ... HMAC_cleanup(&hm); Valgrind reports: ==31996==at 0x4A05809: malloc (vg_replace_malloc.c:149) ==31996==by 0x3C3C6DAD41: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e) ==31996==by 0x3C3C6D8A1D: EVP_DigestInit_ex (in /lib64/libcrypto.so.0.9.8e) ==31996==by 0x3C3C6EB36B: HMAC_Init_ex (in /lib64/libcrypto.so.0.9.8e) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Padding mode for RSA_private_decrypt()...
How can I tell what the padding mode was before I attempt to decrypt data. For example, when I use RSA_private_decrypt(encsize, encdata, decdata, privkey, RSA_PKCS1_PADDING) I sometimes (but not always) get the following error: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Searching the "true" about multithreading
Hi David, On Sat, Nov 7, 2009 at 2:35 PM, David Schwartz wrote: > > Sebastián Treu wrote: > >> The main idea was avoid polling in an infinite loop consuming CPU >> resources. I wrote that code thinking in: "If the particular client >> socket is calling our (thread) attention then fetchs the data". I >> thought on that approach as I don't know another for non-blocking IO >> without a poll cycle. If I loop forever on the SSL_read() function, >> CPU will be kept busy on that job so I thought in a way of not having >> to do so. Instead, something should "inform" that on that socket is >> data ready to be read. > > Right, but your code call 'select' even if it doesn't need to read data from > the socket. > >> Mmmh...I can't see how to do it without select(). The main important >> thing here is that this thread is attending only 1 client. Maybe it's >> confusing because "why use select() then if you are polling always on >> the same IO socket?". Answer: I don't know if there is another system >> call to block until a file descriptor is ready to be read. > > You totally missed my point. You are correct that you need to block > somewhere, you are simply blocking in the wrong place for the wrong reason. > The only reason you should ever block using 'select' on an SSL connection is > because the SSL state machine cannot make forward progress until the socket > is ready. But you call 'select' without knowing this. > >> Then, if I read first with SSL_read() on non-blocking IO, every time >> the client isn't writting or sending anything, the server is using and >> wasting cpu cycles. Without the select() approach and with a maximun >> of 32 clients my cpu usage went to 200% ( 100 per core). With the >> select() approach the cpu usage is relative to the clients >> reading/writting actions. > > What? How does calling SSL_read *first* waste CPU cycles? You *cannot* call > 'select' until you *know* that you need to call 'select'. The data the SSL > state machine needs to make forward progress may already have been read. > >> I believe you are more experienced developer than me (in fact, i'm not >> what you can call A developer) and if not much to ask, how do you >> solve this kind of problem? (without removing the roots of the >> multithreaded server design) I mean, how can you block execution >> waiting for a "noise" on the file descriptor to take some action >> without using select()? > > I guess I wasn't clear. The problem is not that you are calling 'select' at > all, the problem is that you are calling 'select' even when you have > absolutely no reason to do so. > > Call SSL_read. If you make forward progress, great. If you make no forward > progress, the SSL state machine will tell you why. If, for example, it > returns a 'WANT_READ' indication, then you know that the SSL state machine > cannot make forward progress unless it reads from the socket. Then, and only > then, does it make sense to call 'select'. > > Again, you *MUST* get this idea out of your head: > "Read data from socket, decrypt it, pass it to application." > That is *NOT* what SSL_read does. SSL_read is *NOT* a decryption function. > It is an entry point into a state machine that can do all kinds of things, > including reading from the socket. > > Here's where your code blows up horribly: > > 1) You call SSL_write. A renegotiation is in progress, so it reads data from > the socket to see if it can complete the renegotiation. It gets the data > needed to complete the renegotiation and some encrypted application data. It > sends the encrypted data you asked it to, and returns success. > > 2) You enter your broken read function and call 'select', but the data has > already arrived and been read (in step 1). You deadlock waiting forever for > data that is already here. > > Do you see? You cannot call 'select' unless you know for a fact that the SSL > state machine needs to read from the socket. Otherwise you could be waiting > for something that already happened or is not supposed to happen. > > Do not "look through" the SSL state machine. Let it do its job. > > DS > Get it. Excellent explanation. I didn't knew that thing about the state machine. Thanks, Regards, -- If you want freedom, compile the source. Get gentoo. Sebastián Treu http://labombiya.com.ar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Searching the "true" about multithreading
Sebastián Treu wrote: > The main idea was avoid polling in an infinite loop consuming CPU > resources. I wrote that code thinking in: "If the particular client > socket is calling our (thread) attention then fetchs the data". I > thought on that approach as I don't know another for non-blocking IO > without a poll cycle. If I loop forever on the SSL_read() function, > CPU will be kept busy on that job so I thought in a way of not having > to do so. Instead, something should "inform" that on that socket is > data ready to be read. Right, but your code call 'select' even if it doesn't need to read data from the socket. > Mmmh...I can't see how to do it without select(). The main important > thing here is that this thread is attending only 1 client. Maybe it's > confusing because "why use select() then if you are polling always on > the same IO socket?". Answer: I don't know if there is another system > call to block until a file descriptor is ready to be read. You totally missed my point. You are correct that you need to block somewhere, you are simply blocking in the wrong place for the wrong reason. The only reason you should ever block using 'select' on an SSL connection is because the SSL state machine cannot make forward progress until the socket is ready. But you call 'select' without knowing this. > Then, if I read first with SSL_read() on non-blocking IO, every time > the client isn't writting or sending anything, the server is using and > wasting cpu cycles. Without the select() approach and with a maximun > of 32 clients my cpu usage went to 200% ( 100 per core). With the > select() approach the cpu usage is relative to the clients > reading/writting actions. What? How does calling SSL_read *first* waste CPU cycles? You *cannot* call 'select' until you *know* that you need to call 'select'. The data the SSL state machine needs to make forward progress may already have been read. > I believe you are more experienced developer than me (in fact, i'm not > what you can call A developer) and if not much to ask, how do you > solve this kind of problem? (without removing the roots of the > multithreaded server design) I mean, how can you block execution > waiting for a "noise" on the file descriptor to take some action > without using select()? I guess I wasn't clear. The problem is not that you are calling 'select' at all, the problem is that you are calling 'select' even when you have absolutely no reason to do so. Call SSL_read. If you make forward progress, great. If you make no forward progress, the SSL state machine will tell you why. If, for example, it returns a 'WANT_READ' indication, then you know that the SSL state machine cannot make forward progress unless it reads from the socket. Then, and only then, does it make sense to call 'select'. Again, you *MUST* get this idea out of your head: "Read data from socket, decrypt it, pass it to application." That is *NOT* what SSL_read does. SSL_read is *NOT* a decryption function. It is an entry point into a state machine that can do all kinds of things, including reading from the socket. Here's where your code blows up horribly: 1) You call SSL_write. A renegotiation is in progress, so it reads data from the socket to see if it can complete the renegotiation. It gets the data needed to complete the renegotiation and some encrypted application data. It sends the encrypted data you asked it to, and returns success. 2) You enter your broken read function and call 'select', but the data has already arrived and been read (in step 1). You deadlock waiting forever for data that is already here. Do you see? You cannot call 'select' unless you know for a fact that the SSL state machine needs to read from the socket. Otherwise you could be waiting for something that already happened or is not supposed to happen. Do not "look through" the SSL state machine. Let it do its job. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Searching the "true" about multithreading
On Sat, Nov 7, 2009 at 12:47 PM, David Schwartz wrote: > Your logic is backwards here. You are trying to decide whether or not to > read data on the decrypted output link, so why are you 'select'ing on the > encrypted input link? > > SSL is a state machine, not a filter. The implementation of SSL_read is > *NOT*: > 1) Read some data from the socket. > 2) If we got any data, decrypt it. > 3) Return the data we read. > > It is: > 1) Try to make forward progress, doing any reads and writes as necessary. > 2) If this resulted in any decrypted data, return it. > 3) If not, tell the caller why. > > As a result, you can only 'select' *after* calling SSL_read, never before. > And you cannot assume that you will be selecting in the read direction, > because either can be necessary. > > DS Hi David, The main idea was avoid polling in an infinite loop consuming CPU resources. I wrote that code thinking in: "If the particular client socket is calling our (thread) attention then fetchs the data". I thought on that approach as I don't know another for non-blocking IO without a poll cycle. If I loop forever on the SSL_read() function, CPU will be kept busy on that job so I thought in a way of not having to do so. Instead, something should "inform" that on that socket is data ready to be read. Mmmh...I can't see how to do it without select(). The main important thing here is that this thread is attending only 1 client. Maybe it's confusing because "why use select() then if you are polling always on the same IO socket?". Answer: I don't know if there is another system call to block until a file descriptor is ready to be read. That part of code is threaded, and althought you are right on saying: "why a server should have 1,000 threads when you have 1,000 connections", the particular use of this application will be a very-connection-limited server. For example, saying 20 clients is a huge number of connections. The numbers of threads are limited as the number of connections. Then, if I read first with SSL_read() on non-blocking IO, every time the client isn't writting or sending anything, the server is using and wasting cpu cycles. Without the select() approach and with a maximun of 32 clients my cpu usage went to 200% ( 100 per core). With the select() approach the cpu usage is relative to the clients reading/writting actions. I believe you are more experienced developer than me (in fact, i'm not what you can call A developer) and if not much to ask, how do you solve this kind of problem? (without removing the roots of the multithreaded server design) I mean, how can you block execution waiting for a "noise" on the file descriptor to take some action without using select()? I really appreciatte your concern on letting me know my errors and sorry if this invalidate the main topic thread, Regards -- If you want freedom, compile the source. Get gentoo. Sebastián Treu http://labombiya.com.ar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Searching the "true" about multithreading
Sebastián Treu wrote:
> I used a select() thread with non-blocking IO just to no keep the cpu
> busy in a infinite loop. Kind of:
>
> while( alive && CONTINUE )
> {
> /* The main client attendance */
>
> copy = master;
> if ( select(client->fd+1, ©, NULL,NULL,NULL) == -1)
> printf(":[ERR]:\tSelect fail\n",tid);
> else
> {
> if ( FD_ISSET(client->fd, ©) )
> {
> /* read from the secure connection gaining exclusive
> access */
> /* to the client ssl structure. The 'sender thread' could
> */
> /* access this structure coliding with the 'err' value
> and */
> /* starting a catastrophe.
> */
> pthread_mutex_lock(&client->mutex[SSL_MUTEX]);
> nbytes = SSL_read(client->ssl, client->buffer,
> chunk_size);
> err = SSL_get_error(client->ssl, nbytes);
> pthread_mutex_unlock(&client->mutex[SSL_MUTEX]);
>
> You can check the hole threaded server in earlier development here:
>
> http://code.google.com/p/tellapic/source/browse/trunk/server.c
Your logic is backwards here. You are trying to decide whether or not to
read data on the decrypted output link, so why are you 'select'ing on the
encrypted input link?
SSL is a state machine, not a filter. The implementation of SSL_read is
*NOT*:
1) Read some data from the socket.
2) If we got any data, decrypt it.
3) Return the data we read.
It is:
1) Try to make forward progress, doing any reads and writes as necessary.
2) If this resulted in any decrypted data, return it.
3) If not, tell the caller why.
As a result, you can only 'select' *after* calling SSL_read, never before.
And you cannot assume that you will be selecting in the read direction,
because either can be necessary.
DS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Linking and execution problems with a FIPS-capable OpenSSL distribution
Synopsis: Linking and execution problems with a FIPS-capable OpenSSL distribution. System: -- openSUSE 11.0 (i586) Linux version 2.6.25.20-0.4-pae gcc (SUSE Linux) 4.3.1 OpenSSL 0.9.8g 19 Oct 2007 (currently installed) Includes are in /usr/include/openssl Libs are in /usr/lib Fips/OpenSSL Versions: - openssl-fips-1.2.tar.gz openssl-0.9.8l.tar.gz Goal of this post: - 1. Additional clarification on the linking process as described in the User Guide and comment as to whether my workarounds are correct and in accordance with the Security Policy. 2. Help on overcoming the "fingerprint does not match" runtime error. Description: --- I have read the UserGuide-1.2.pdf and SecurityPolicy-1.2.pdf numerous times and have also scoured the news groups searching for a solution to my problem. I am trying to link fipscanister.o and libssl into a shared library, specifically, the ACE_SSL library that is part of the latest ACE distribution from the ACE/TAO group. The User Guide is somewhat vague on whether this can be done. From my understanding, linking fipscanister.o and libssl into a shared library is possible since my shared library is considered an application as defined in the User Guide. So here is what I am doing... Per the User Guide, I do the usual after successfully performing the two verification steps: openssl-fips-1.2 # ./config fipscanisterbuild make make install openssl-0.9.8l # ./config fips make make install As a non-su user, I modify the environment per the User Guide as follows: export FIPSLD_CC=gcc export CC=/usr/local/ssl/fips/bin/fipsld export CXX=/usr/local/ssl/fips/bin/fipsld I also copied the openssl include directory from /usr/local/ssl/fips/include/openssl to /usr/local/include which will be found by gcc. If I did not do this, gcc would find my existing openssl headers located at /usr/include/openssl. Finally, I modify my LD_LIBRARY_PATH environment variable to include /usr/local/ssl/fips/lib prior to the /usr/lib include so that ld will find the Fips-capable OpenSSL library. When I execute the ACE_SSL shared library make, I get the following output and error: /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith -O3 -ggdb -pipe -D_REENTRANT -DA$ /usr/local/ssl/fips/bin/fipsld -Wl,-O3 -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE -I/home/linuxbuild/ntsdev/3rdParty/ACE_wrappers_L$ /usr/local/ssl/fips/bin/fipsld: line 94: /usr/local/ssl/fips/bin/../fips/fips_standalone_sha1: No such file or directory 1d0 < HMAC-SHA1(fips_premain.c)= 9e5ddba185ac446e0cf36fcf8e1b3acffe5d0b2c /usr/local/ssl/fips/bin/../lib/fips_premain.c fingerprint mismatch The fips_standalone_sha1 program is located in: /usr/local/src/openssl-fips-1.2/fips/fips_standalone_sha1 /usr/local/src/openssl-0.9.8l/fips/fips_standalone_sha1 So, I modified the environment as follows to have access to fips_standalone_sha1: export FIPSLD_CC=gcc export CC=/usr/local/src/openssl-fips-1.2/fips/fipsld export CXX=/usr/local/src/openssl-fips-1.2/fips/fipsld This succeeds in linking the shared library; however, it seems like the fips_standalone_sha1 and other dependent files should have been copied to /usr/local/ssl/fips/fips as the headers, modules, and libraries were. It seems that the User Guide could add some explanation on the various duplicate file copies. Anyways, I then compile and link my application to the shared library created above using gcc/ld instead of fipsld. I also tried compiling and linking my application with fipsld but it did not make a difference. When my application runs and calls FIPS_mode_set, I get an error of "fingerprint does not match." Relevant Environment When Building/Linking the ACE_SSL Shared Library with fipscanister.o and libssl: - LD_LIBRARY_PATH = :/home/linuxbuild/ntsdev/3rdParty/ACE_wrappers_Linux/lib:/usr/lib/oracle/xe/app/oracle/product/10.2.0\ /server/lib:/usr/local/ssl/fips/lib:/usr/local/lib:/usr/lib: FIPSLD_CC=gcc CC=/usr/local/src/ope
Re: Signature Verification
Hi, In order to help you further, can you post : - The data to be hashed which is the content of your variable xmlDat - The signature to be verified which is the content of your variable sigDat (maybe it's what you posted first) - The public key that will be used for the verification - The endianess of the the signature. It should be big endian as expected by OpenSSL And just one last confirmation : In your first email, you posted some BASE64 data that you say is the signature. This data is 512 bytes long. So this would mean that the key used is a 4096 bit RSA key. Is this correct? Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello Again, The code is there to check for a non-null pkey. It wasn't copied to keep the original message shorter. I've now made sure that I've Base64'd the xml string and Base64'd the signature string. These are what I'm giving to the EVP_VerifyUpdate and EVP_VerifyFinal. Still not verifying. Thanks Again, Jim - Original Message - From: "Mounir IDRASSI" To: Sent: Friday, November 06, 2009 5:11 PM Subject: Re: Signature Verification Hi, You must also handle BASE64 decoding in EVP_VerifyUpdate not only EVP_VerifyFinal. Those two functions must have as input the byte arrays that represent the binary data and the binary signature respectively. Concerning PEM_read_PUBKEY, if it returns a non NULL pointer then everything is OK with the public key and you don't have to worry. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hi, Thank you for the response. It was sha512 not 256. I changed it to EVP_sha512 in the code but it still won't verify. On the verify final, I've tried it both with and without a Base64 converted string (and corresponding length). I'm not sure from what I've read if the PEM_read_PUBKEY does a Base64 conversion on the Public Key or not and I'm not sure where to look in the pkey to find out. Jim - Original Message - From: "Mounir IDRASSI" To: Sent: Friday, November 06, 2009 3:55 PM Subject: Re: Signature Verification Hi, In your description you say that the signature was created with SHA256 but in your code you are using SHA-1 through EVP_sha1. Replace this with EVP_sha256 to have a correct processing. Also, your data seems to be BASE64 encoded and you are computing the digest directly on the BASE64 string. You should convert this BASE64 string to the corresponding byte array and then compute the digest on this byte array. I hope this will help. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jim Welch wrote: Hello, I've been trying to verify the signature from the following xml data: 1.0EC1000-090001800:54:66:18:3A:40code="impedance">2000-01-012099-12-31code="multimeter">2000-01-012099-12-31code="sulfation">2000-01-012099-12-31AA80A2A7119FD4F1C122080E1AD17490 using this signature: C4S953HqB8S/SZ8nOO5IgGA0Vm3BxHT8vByWJFG2gn/OrBKc45QvjEdX855bb9p8KdSa1YQt3nnv p6MCA+5YCDePEIuYpbTYzAIJ9p7zqpJsXzb8YlDpw4qpf0TSbCCEFZZReSRSAxlE2gH/SOvPAjRY ykvxbjrgMQ07Jf/ae4lX+CaBxA/Az8efhsBDyT6wCPECkj1SiufTtVA2MAt9Bf76Y1T5RnHph/kf Hj3/osgrMKKbIPhii2nPktMH223QfgmTOtHxw21ahi2vcSnADb9p1WIjDiq/gLk0uisT/p0g4MZb SKNOct3MRqgv64wtyUD+W/+8/yGQK+/IXNIhgKoKsvuwR242c7RpF+HdVZRrfeIQMnUAAo/7q+rS AzRJO7L7xoXYvFOmVxvjRZP8Rhw445N6bnLwLxANFNvyoo5ykGdocBUEBMD5sC3TipYUti39mso2 dsqSMwtRhPDw9dzf6evwG3+Qo0ewLVap3pNu8XzBrXxCM6pv7IydmekiHvSF6OFrt/rPUA2pXyuU njhD/twe0+n5fLlSTZ6w/D898e/blvFUroQbmaI8Rr7AE9fZY0KJBuc73YgPTXOnm4Iqc/5vMwId j27g+JGWEzjyAtNIBo9Su0/9LE1IVPyZgAjquBEmKEAcQQjnW4D8kj2mllJLRwI00e1TAwE9Klo= These two strings above are being sent from a server as one file which I parse into the two separate strings making sure white space has been removed from the xml as that was how it was signed. The signature was created with RSA & SHA512. I'm using a C program to verify and have tried numerous attemps with no sucess. The openssl release is 0.9.8k. The vars sigDat and xmlDat are the respective strings. The code is as follows (some parts left out for simplicity): fp = fopen (filePubKey, "r"); pkey = PEM_read_PUBKEY(fp, NULL, NULL, NULL); EVP_VerifyInit (&md_ctx, EVP_sha1()); EVP_VerifyUpdate (&md_ctx, xmlDat, strlen(xmlDat)); err = EVP_VerifyFinal (&md_ctx, sigDat, strlen(sigDat), pkey); EVP_PKEY_free (pkey); Any ideas as to what is wrong. Another part of the project here involves java and the programmer working on that says that he can verify the signature so I know that the data is correct. Thank You, Jim Welch __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http
