Re: unsealing EVP_Seal... from command-line
On 2006.10.12 at 18:44:20 -0400, William Triplett wrote: Dear openssl-users, Suppose that I have the Sealed Data, Envelope, and proper Private Key for some data encrypted with EVP_Seal* using RC4 (basically, PHP's openssl_seal() function). Is there a way to decrypt it using the command-line openssl tools? I think that you should look to openssl smime command. EVP_Seal* is public key encryption which generate random session key, encrypts it with private key and envelopes into some ASN1 structure. try openssl smime -decrypt -in envelope -inform PEM -content sealed You might have to add proper PEM header and footer to envelope. Or decode base64 separately and use DER format. You also have to base64 decode sealed data before feeding to decryption routine. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
sslv3 alert handshake failure
I've generated ECC cert using openssl and was testing with the command:openssl s_client -connect localhost:443.Error was encountered:2028:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:.\ssl\s23_clnt.c:562: Anyone has a idea what the error could mean?I can't be sure whether it's a server or a ECC cert issue?All advice would be appreciated. Thanks in advance! What is the internet to you? Contribute to the Yahoo! Time Capsule and be a part of internet history.
RE: How to share SSL session when using CreateProcess/execv
David, Agreed. If any object in shared memory contained a pointer to another object in shared memory this could cause a problem. You would have to ensure that the shared memory was mapped to the same address in all processes otherwise the pointers would not be valid. Since he's talking about a process that forks, there shouldn't be a problem. He just needs to create a shared mapping in the parent. After the 'fork', the address will still be the same. However if the program forks and calls exec* then this issue could arise. The title of the thread suggests this ;-) Cheers, Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Don Dhondt/US/BULL is out of the office.
I will be out of the office starting 10/13/2006 and will not return until 10/23/2006. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How to share SSL session when using CreateProcess/execv
Since he's talking about a process that forks, there shouldn't be a problem. He just needs to create a shared mapping in the parent. After the 'fork', the address will still be the same. However if the program forks and calls exec* then this issue could arise. The title of the thread suggests this ;-) Cheers, Mark Yeh, you are quite right Mark as when this thread started, I was considering fork()/exec() scenario. Later the discussion over several other approaches to the problem were discussed and an attempt to solve the problem by getting rid of exec() was under consideration. As far as the application that I am working on is concerned, it already has a mechanism in place to map the shared memory at exactly the same address in all the related processes. So no issue withe the address there. Of course, it will be great to have a feature in OpenSSL implementation iteslf that will enable SSL session handover / or even session sharing between multiple related processes. But I am not quite sure if this would involve any security hazards like session hijacking, that would in fact defete the purpose of SSL (which is to provide security). ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to share SSL session when using CreateProcess/execv
The point of SSL is to provide (possibly) data integrity (detection of tampering and validation of the source of the data) and secrecy services /on the wire/. The endpoints have always been known to be points of concern as they must maintain the keys, both private and symmetric, in their memory space somewhere. Putting these keys in shared memory arguably reduces overall security, by bypassing the OS's normal mechanisms of process memory isolation. This should certainly be an implementation concern, because if your webserver gets compromised through a buffer overflow, integer misreflection (overflow or fencepost errors on arrays for example), or any other remote code execution vulnerability, then the shared memory is readable. In practice, this doesn't matter all that much because it's very likely that the process that's compromised is running in the same context as the key manager anyway. The way OpenSSL works, unless it has an ENGINE doing its encryption work for it, the keys are in accessible memory. (Unless the ENGINE is a tamper-resistant/detectant piece of hardware, they keys are going to be in accessible memory again/as well.) Also, OpenSSL's memory space is vulnerable to a debugger. This has also always been the case. These are issues that are common to all software SSL/TLS implementations. Without adequate OS security, putting encrypted data on the wire is like putting a deadbolt with an integrated alarm on a pressboard door, and leaving the windows open. These are some of the issues that need to be taken into consideration when deciding whether to allow SSL/TLS connections to be passed back and forth, not merely allowing SSL/TLS sessions to be resumed (which implies keeping the session state for some period of time). Since UNIX domain sockets can pass file descriptors back and forth, the ability to pass SSL and SSL_CTX objects back and forth as well might be useful... but it's not important enough to me for me to code it. :) -Kyle H On 10/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Since he's talking about a process that forks, there shouldn't be a problem. He just needs to create a shared mapping in the parent. After the 'fork', the address will still be the same. However if the program forks and calls exec* then this issue could arise. The title of the thread suggests this ;-) Cheers, Mark Yeh, you are quite right Mark as when this thread started, I was considering fork()/exec() scenario. Later the discussion over several other approaches to the problem were discussed and an attempt to solve the problem by getting rid of exec() was under consideration. As far as the application that I am working on is concerned, it already has a mechanism in place to map the shared memory at exactly the same address in all the related processes. So no issue withe the address there. Of course, it will be great to have a feature in OpenSSL implementation iteslf that will enable SSL session handover / or even session sharing between multiple related processes. But I am not quite sure if this would involve any security hazards like session hijacking, that would in fact defete the purpose of SSL (which is to provide security). ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Source for entropy on Windows platforms with CryptoAPI installed
It just occurred to me that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed (type REG_BINARY) contains the latest seeded value from everything that CryptoAPI takes into account when generating its random seed. CryptoAPI permutes it with RC4 to come up with a pseudo-random stream, but I wonder if it might make sense to try to make use of it the same way OpenSSL on UNIX uses /dev/urandom? Just a thought. -- -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: How to share SSL session when using CreateProcess/execv
Of course, it will be great to have a feature in OpenSSL implementation iteslf that will enable SSL session handover / or even session sharing between multiple related processes. Session sharing is pretty hard to do. Handover is not quite as hard. I think that would be a really great feature. The trick is to create code to serialize (into BER, I would imagine) all of the SSL session state information into a form that is independent of any other structures. On the flip side, you need to create the session object from the BER data and then create session-private copies of any associated structures needed to support the session (and get rid of them when you're done with the session or hand it off). If you standardize the format, it should be possible to hand a session off even across different versions of OpenSSL and, eventually, across different SSL implementations. (Does anyone know if there is such a standard already?) But I am not quite sure if this would involve any security hazards like session hijacking, that would in fact defete the purpose of SSL (which is to provide security). SSL is only secure if the endpoints are secure. SSL secures the transport and ensures you got the endpoint you intended. However, there are some security issues that do need to be addressed. For example, to support renegotiation, you have to hand off the private key along with the session (I think). That could present some security issues in that anyone who ever gets a session would have to be trusted with the private key. Another possible issue might be that it would be difficult to get session handoff to work properly with session caching. In that case, the loss of session caching could make a DoS attack possible or easier. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
i have a question ragarding self-signed certificate
guys: we all know that a ca-signed certificate can provide authentication because the ca is trustable, by using ca-signed certificate, one is saying i am somebady because the ca says so. but it seems that a self-signed certificate _cannot_ provide any authentication at all, because by using self-signed certificate, one is saying i am somebody because i say so. if my understanding is correct, then why self-signed certificate is still used? thanks. chong peng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: i have a question ragarding self-signed certificate
Recall that even the 'ca' certificate is ultimately self-signed. So your question is really about why some self-signed certificates are more trusted than others. In some fashion you could ask this question about any typical 'brand name' store. Why is Store-X trusted more than Store-Y? Simply because more people (or at least the person in question) has more experience with Store-X. Similarly for any particular self-signed CA cert, although we replace experience here with 'it is already in my certificate store', it is more trusted if the client knows about it already. Now what if Store-Y isn't a chain store. Instead it is a little local boutique? Perhaps there isn't a need/expectation that a brand name and national marketing campaign is required; but they'd still like people to recognize their letterhead. So a logo and a local 'brand' is all that is required. Similarly if all I want is for people to recognize my self-signed certificate I don't really need a CA, a pki hierarchy and all that. One self signed certificate should be enough... If I've made things confusing with my metaphor you could also just think about the model for ssh... it is often valuable just to be able to know you're communicating with the same person you communicated with last time. - max On Oct 13, 2006, at 5:02 PM, Chong Peng wrote: guys: we all know that a ca-signed certificate can provide authentication because the ca is trustable, by using ca-signed certificate, one is saying i am somebady because the ca says so. but it seems that a self-signed certificate _cannot_ provide any authentication at all, because by using self-signed certificate, one is saying i am somebody because i say so. if my understanding is correct, then why self-signed certificate is still used? thanks. chong peng __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Either a bug or a misunderstanding or Spyders in the code
I am trying to do encryption using the evp APIs. For testing I am
using AES-128-ECB as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
My program is largely the same as evp_test.c function test1 with
the release /openssl-0.9.8c/test, however this program does not
handle the padding -- all the test cases have even block-count bytes
and the padding is turned off. I removed the call to turn off the
padding in my program. My program is also like a sample program I
found on-line which handles the padding the same as I
do: http://tldp.org/LDP/LG/issue87/vinayak.html
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(ctx,out,outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(ctx,out+outl,outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(ctx,out,outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(ctx,out+outl,outl2)) {
outl2 is set to zero ...
It would seem that the first encrypt SHOULD set 32, the final encrypt
should set 16 and the final result should then be 48 bytes.
It would also seem that the first decrypt should set 32, the final
decrypt should set 5, and the final result should be 37 bytes.
At a bare minimum, it would seem that the total from the two
encrypt statements should be 48 and the total from the two decrypt
statement should be 37 or 48, depending on your taste, but I find 37
more useful. Last, I should not have to store 64 bytes of encrypted
data to successfully encrypt and decrypt 37 bytes of data.
I have noticed that if I simply don't do the final calls for both
encrypt and decrypt that everything appears to work on the encrypt
and I save 48 bytes ... but when I decrypt it I only get back 32
bytes. And if I do a final decrypt on data that did not have a final
encrypt I get an error.
I suspect I am missing something because using openssl to encrypt the
bytes from a file and in to a file yields a 64 byte file ... just
like my program :-) But I don't understand why.
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
This email sent by:
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
928-301-7537 -- you may call any time day or night, I turn it off
when I sleep :-) Please try to use a land line first (reception often poor).
Note the change in the domain from vicspdi.com to vicsmba.com
For Metropolis support and VICS MBA Support
http://www.vicsmba.com
Completely updated web site of personal pictures with many new
pictures! Includes horses, dogs, Corvairs, and more.
http://www.vicsmba.com/ourpics/index.html
Corvair pictures including the Judson setup on our 62 Sedan and lots
of pictures of Cheryl's 62 Monza Wagon and our 62 Spyder convertible.
http://www.vicsmba.com/ourpics/corvairs.html
My younger brother Martin has started a very serious car company. A
hot rod (very fast) electric roadster is the first offering. The
chassis is built by Lotus to their specs. Check it
out: http://www.teslamotors.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Either a bug or a misunderstanding or Spyders in the code
OpenSSL does not store the plaintext size in block protocol usage.
That's an application-layer issue.
ECB mode, by the way, is REALLY discouraged.
Padding doesn't come into play until the second-to-last and last
blocks. You should get 16*(3 blocks of data +1 block for the
EncryptFinal()) == 64 bytes.
If you're writing less than a multiple of the block size, you should
call EncryptFinal() on that write, not follow it up. This is arguably
a bug in the block logic (the expected behavior you seem to want would
be: you should get 32 bytes from the write of 37 bytes, with the final
5 bytes stored in a buffer until you call EncryptFinal, which would
pad to the appropriate block length and then finish the encryption),
but I'm not certain it should be changed -- SSL and TLS have a need
for an application data flush feature that forces data to be flushed
without the encryption state being reset.
Every EncryptFinal() ciphertext block that you get from it, though, is
going to be the same (at least in ECB mode). Personally, I regard the
fact that OpenSSL supports ECB mode without a Configure option (or at
least a warning when it's used) a bug.
So, to answer your questions in order:
1) The second-to-last block is not an extra block. It contains
application data. I believe that you can expect to get that last
block.
2) No.
3) I think you're missing something.
4) Padding doesn't happen until a short block occurs anyway, so
turning padding off until the final block won't change anything. Look
at the source code to the command-line utility to see what it does, if
you want to get identical results.
Cheers,
-Kyle H
On 10/13/06, Eric S. Eberhard [EMAIL PROTECTED] wrote:
I am trying to do encryption using the evp APIs. For testing I am
using AES-128-ECB as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(ctx,out,outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(ctx,out+outl,outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(ctx,out,outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(ctx,out+outl,outl2)) {
[...]
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Either a bug or a misunderstanding or Spyders in the code
Kyle,
Thank you ... I thought I was missing something (actually the
behavior told me what you told me, I just wanted to confirm it was
correct). I won't actually use ECB, it was randomly selected from
the test file ...
A follow-up then ... if I have 37 bytes I would call Update twice and
Final once? If I have 32 bytes I would call Update once and Final
once? Or two Updates?
Is there a call to get the block size, or is that always 16? (I know
it is in the ctx but I was hoping to get it sooner than that).
Thank you again!
Eric
At 06:27 PM 10/13/2006, you wrote:
OpenSSL does not store the plaintext size in block protocol usage.
That's an application-layer issue.
ECB mode, by the way, is REALLY discouraged.
Padding doesn't come into play until the second-to-last and last
blocks. You should get 16*(3 blocks of data +1 block for the
EncryptFinal()) == 64 bytes.
If you're writing less than a multiple of the block size, you should
call EncryptFinal() on that write, not follow it up. This is arguably
a bug in the block logic (the expected behavior you seem to want would
be: you should get 32 bytes from the write of 37 bytes, with the final
5 bytes stored in a buffer until you call EncryptFinal, which would
pad to the appropriate block length and then finish the encryption),
but I'm not certain it should be changed -- SSL and TLS have a need
for an application data flush feature that forces data to be flushed
without the encryption state being reset.
Every EncryptFinal() ciphertext block that you get from it, though, is
going to be the same (at least in ECB mode). Personally, I regard the
fact that OpenSSL supports ECB mode without a Configure option (or at
least a warning when it's used) a bug.
So, to answer your questions in order:
1) The second-to-last block is not an extra block. It contains
application data. I believe that you can expect to get that last
block.
2) No.
3) I think you're missing something.
4) Padding doesn't happen until a short block occurs anyway, so
turning padding off until the final block won't change anything. Look
at the source code to the command-line utility to see what it does, if
you want to get identical results.
Cheers,
-Kyle H
On 10/13/06, Eric S. Eberhard [EMAIL PROTECTED] wrote:
I am trying to do encryption using the evp APIs. For testing I am
using AES-128-ECB as the cypher. I have no problem encrypting and
decrypting, rather I am having problems with the sizes of the buffers.
When encrypting a string of 37 bytes and passing as such:
if (!EVP_EncryptUpdate(ctx,out,outl,plaintext,37)) {
outl becomes 48 at this point (which is the expected size since this
alogrithm appears to block at 16 bytes). However, the next call as such:
if (!EVP_EncryptFinal(ctx,out+outl,outl2)) {
this sets outl2 to 16 ... meaning it padded one more additional block.
If I send decrypt 64 bytes it gives the desired answer (e.g. my text
is what I expect it to be). This is what I send:
if (!EVP_DecryptUpdate(ctx,out,outl,ciphertext,64)) {
outl is set to 48 (I would really like it to be 37 ...)
if (!EVP_DecryptFinal(ctx,out+outl,outl2)) {
[...]
1) Should I always count on up to 2 extra blocks (1 for the remainder
if any, one for no reason I can tell)?
2) When decrypting, is there a way to find out the original size (in
my case 37)?
3) Am I missing something or is there a bug around here?
4) If I am going to handle large files that require multiple calls to
the Encrypt routines, I presume I would turn the padding off until
the very last block of data? Same with decrypt? My goal would be to
be able to encrypt a file and get the exact same results as command
line openssl. And the reverse.
Thanks,
Eric
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
This email sent by:
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
928-301-7537 -- you may call any time day or night, I turn it off
when I sleep :-) Please try to use a land line first (reception often poor).
Note the change in the domain from vicspdi.com to vicsmba.com
For Metropolis support and VICS MBA Support
http://www.vicsmba.com
Completely updated web site of personal pictures with many new
pictures! Includes horses, dogs, Corvairs, and more.
http://www.vicsmba.com/ourpics/index.html
Corvair pictures including the Judson setup on our 62 Sedan and lots
of pictures of Cheryl's 62 Monza Wagon and our 62 Spyder convertible.
http://www.vicsmba.com/ourpics/corvairs.html
My younger brother Martin has started a very serious car company. A
hot rod (very fast) electric roadster is the first offering. The
chassis is built by Lotus to their specs. Check it
out: http://www.teslamotors.com
