Re: EVP_Open* with a public key
On 27-Jul-09, at 12:05 PM, David Schwartz wrote: Jeremy R. wrote: Okay, forgive my ignorance, but isn't the most common way of signing data simply taking a cryptographic hash (SHA-1, RIPEMD-160, WHIRLPOOL, etc.) and then encrypting it with a public-key technology? Yes, that's the most common way. But it is not a general property of public-key encryption. It just happens to be true of RSA and RSA just happens to be popular. But you cannot conclude automatically that a system has the properties of its components. By definition, isn't any public-key technology (including RSA) guaranteed to make it impossible to determine the key used to encrypt data, even if the key used to decrypt it is known? Yes, but that is valid for encryption only because it is an intentional property of encryption and any scheme that didn't have it would be useless. But if it's so for signing, it's only an accidental property. So it may or may not be maintained by the system. Did you understand my example of a system that bundles the public key with the signature? Why would that not be a perfectly valid signature scheme? If that's the case, then how is it possible to compromise the key used to sign the data based on having a signature and the corresponding key? I guess you're not reading what I'm writing. Let's try it again. Consider an RSA signature scheme that bundles the public key in with the signature. This would be a perfectly valid signature scheme and would meet all of the general security properties of public key signature schemes. Yet a signature in this scheme *would* compromise the public key. Are you with me so far? So there is no automatic guarantee that a signature scheme that happens to use RSA internally happens to preserve this one particular security property of RSA because it is not typically relevent to signature schemes. I understand, but realize that I am coding the application, so I can choose to use a signature scheme that does not include the public key. In the case of an envelope (the other use I want to use the key pair with), I'm relying on the same goal. I need to be sure that nobody can determine the key used to encrypt the symmetric key, even given the key used to decrypt it. That's the goal of public-key cryptography, unless I'm that far off the mark. That's the goal of public key encryption. The goal of public key signatures is simply to ensure the signature cannot be forged and the secret key is not compromised. Not compromising the public key is not generally a goal of public key signature algorithms. So you need to find a complete signature algorithm that is guaranteed to have this property. But RSA, from what I understand, doesn't by definition make one key public and the other private. Unless I'm really mistaken, you create a key pair, whereby data encrypted with either can be decrypted only by the other. I think it's only by convention that one is private and the other is public. Both of these separately are quite frequent uses for RSA (built into OpenSSL), so my question is this: why does using the same key pair weaken the system? If there is significant reason that it would, putting an additional kilobyte into my client application isn't a huge hardship; it just seems inelegant. You don't get to make that decision. Either not compromising the public key is a property of the full signature algorithm you are using or it's not. If it's not, you cannot deduce the property. You can only rely on guaranteed properties of the outer, entire algorithm you are using. DS __ 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: EVP_Open* with a public key
On 27-Jul-09, at 9:59 PM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of David Schwartz Sent: Monday, 27 July, 2009 12:06 Jeremy R. wrote: Okay, forgive my ignorance, but isn't the most common way of signing data simply taking a cryptographic hash (SHA-1, RIPEMD-160, WHIRLPOOL, etc.) and then encrypting it with a public-key technology? Yes, that's the most common way. But it is not a general property of public-key encryption. It just happens to be true of RSA and RSA just happens to be popular. But you cannot conclude automatically that a system has the properties of its components. For example, it's not true at all for DSA (aka DSS). And although in raw RSA encrypt/decrypt and sign/verify are mathematically equivalent, the common schemes built on RSA (PKCS1 type1 and PSS for sign, type2 and OAEP for encrypt) are different, so you can't just reuse the code. In addition to David Schwartz' concern about direct exposure of the pubkey, since PKC designs in general don't strive to protect it, RSA (pub)keys frequently have a small pubexpt since this is more efficient (public side doesn't know factors) and for usual uses it is exposed anyway. RSA keys generated by openssl do this, and so do many (most?) other common systems. Then only the modulus needs to be found to break your scheme. Now that I did not know. That's interesting to learn. I don't think the amount of data Eve could feasibly collect is enough to do that, but IANAMathematician so get a real expert if you care. But if Mallory can detect any difference (even timing) for purported keytransfer OR signature values exceeding the modulus or not, he can determine the key in probably a few thousand probes. If you do your own generation with a fullsize random pubexpt, you might be safe, but pubkey=client operations will be MUCH slower for a large key (as you said you use), if that matters. Another idea: you're not using the benefit of PKC encryption (unknown to one). Why not just symm-encrypt the data? You could use (a hash of) the RSA pubkey and it would be efficient, but still at risk if the pubkey is exposed or analyzed. Alternatively if you (can) have other secret data in (or with) your client you can use that; it doesn't need to have a specific internal structure like RSA (or some other PKC) keys do. Well, envelopes do have the benefit that it's only the symmetric key that's encrypted, so it shouldn't be that slow to decrypt the 32 bytes for the symmetric key. But yes, if I would have to create a second key pair anyhow, I may simply create a shared symmetric key instead – the signature should be enough to prevent forgery (right? I think that's the point of signatures). That was my original approach, until the thought of using envelopes occurred to me, since I was already creating a key pair. If reusing this key pair is really a bad idea, as is apparently the case (two people who know more about cryptography than me is enough to make me fairly sure of that), then adding another 32 bytes to my application isn't the end of the world by any means. By the way, as far as IVs go, I'm currently generating a random IV and tacking that onto the beginning of the message, which I believe is fairly common. Is there anything wrong with this? Should I be using a static IV (I would think that would be less secure, but I'm not an expert). PS- the correct spelling for the attack on PKCS#1 type2 padding is Bleichenbacher, if you want to find out about it. Oh, and in case I haven't said it before, thank you both for your help – it's greatly appreciated.
Re: EVP_Open* with a public key
Okay, forgive my ignorance, but isn't the most common way of signing data simply taking a cryptographic hash (SHA-1, RIPEMD-160, WHIRLPOOL, etc.) and then encrypting it with a public-key technology? By definition, isn't any public-key technology (including RSA) guaranteed to make it impossible to determine the key used to encrypt data, even if the key used to decrypt it is known? If that's the case, then how is it possible to compromise the key used to sign the data based on having a signature and the corresponding key? In the case of an envelope (the other use I want to use the key pair with), I'm relying on the same goal. I need to be sure that nobody can determine the key used to encrypt the symmetric key, even given the key used to decrypt it. That's the goal of public-key cryptography, unless I'm that far off the mark. Both of these separately are quite frequent uses for RSA (built into OpenSSL), so my question is this: why does using the same key pair weaken the system? If there is significant reason that it would, putting an additional kilobyte into my client application isn't a huge hardship; it just seems inelegant. On 25-Jul-09, at 9:56 PM, David Schwartz wrote: Jeremy R. wrote: It's also a good reason to understand why my solution isn't valid (assuming it isn't) so that I have the understanding to correctly engineer future programs that use cryptography. Because it relies on special properties of the RSA internals where those properties are not intended to be, nor guaranteed to be, maintained by the outer algorithms. The public key is not transmitted over the wire – all clients are known to have the key in advance (it's built in), so it will never be transmitted as a part of the message. Not intentionally. But what's the guarantee that the messages sent won't compromise the public key? Do you know of any signature algorithm that specifically guarantees that signatures will not compromise the public key? Is that the algorithm you're using? Note that RSA *directly* is not a signature algorithm -- attempts to use RSA alone as a signature algorithm have been demonstrated to be insecure. For example, the following would be a perfectly reasonable RSA signature algorithm: 1) Take in the public key, private key, and data to be signed. 2) Checksum the data to be signed. 3) Sign the checksum with the private key. 4) Create a structure including the signature, checksum, and public key. Output that as the signature. As the public key will already exist on the clients, I only intend to send the encrypted checksum, not the public key. Of course that's all you intend. But the issue is not what you intend but what you actually *do*. You are using some signature algorithm X that uses RSA internally. You are assuming that X will have security properties that RSA will have. That is only a valid assumption if you can prove it. Can you do that? I'm betting you can't. You cannot use RSA directly as a signature algorithm, see for example, Daniel Belichenbacker's 1998 paper, John Hastad's attack on RSA, and various chosen-ciphertext attacks. You must use a signature algorithm that uses RSA internally. As a result of this, you gain the security properties of that outer algorithm, but you lose the ability to claim that known properties of RSA itself are properties of your algorithm unless you can show they are. DS __ 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: EVP_Open* with a public key
On 25-Jul-09, at 6:30 AM, David Schwartz wrote: Jeremy R.: Thanks for your reply, first of all. I'm by no means an expert in cryptography (and obviously not on OpenSSL), and I'd appreciate any insight you can provide. So that's a good reason not to invent your own solution. It's also a good reason to understand why my solution isn't valid (assuming it isn't) so that I have the understanding to correctly engineer future programs that use cryptography. Yes, but what I have neglected to mention is that this information will be broadcast from my server to all instances of the client application. Therefore, anyone with access to a copy of the client application will be able to decrypt the message, period. Or anyone who gets the public key off the wire. The public key is not transmitted over the wire – all clients are known to have the key in advance (it's built in), so it will never be transmitted as a part of the message. I think you misunderstand. My message format works like this: my application's data is already signed by the server's private key. As a result, it has a copy of the public key. The public and private keys are part of a key pair. From what I understand, RSA makes no distinction between which key is public and which is private, only that data encrypted with one can only be decrypted with the other. So I already have a key pair established, and the client is only aware of one key, which is currently used only for signature verification. Could I not also use that key to decrypt the symmetric message key? Yes, if you could show that no attacker could have that public key. But I don't think you can show that. The corresponding key, which only the server has, and is currently termed the private key, is not known to the client. It is my understanding, then, that I should be able to use this key to encrypt my message, and that message will only be able to be decrypted by the client's key. Why should I need to create a second RSA key pair, when I already have a perfectly good 4096-bit key pair between the client and server applications? Because you probably don't have a way to sign the data from the server that is guaranteed not to reveal the public key. For example, the following would be a perfectly reasonable RSA signature algorithm: 1) Take in the public key, private key, and data to be signed. 2) Checksum the data to be signed. 3) Sign the checksum with the private key. 4) Create a structure including the signature, checksum, and public key. Output that as the signature. As the public key will already exist on the clients, I only intend to send the encrypted checksum, not the public key. This would be a perfectly reasonable signature algorithm, but it would also reveal the public key to the public. Any attacker possession such a signature could trivially extract the public key -- since it's in the signature. You need to prove that no attacker can have the public key to use this method. If you can do that, then more power to you. But what I'm trying to say is that I don't think you can. The public key (the client's key) will only be distributed with the client application. Right, but it may also be revealed by your wire protocol. If you trust the wire, why are you bothering with all this trouble? If you don't trust the wire, how can you be sure the public key will only be distributed with the client application? In the event that the client's key is compromised, I may implement a re-keying mechanism that allows the server to give the clients a new key. That assumes you know the public key is compromised. DS __ 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
EVP_Open* with a public key
I'm writing a client application that needs to verify some content from a server. I've generated an RSA key pair: the private key for the server and the public key for the client. I also would like the data to be encrypted, so I'm trying to use EVP_OpenInit on the receiving end to do my decryption. I'm reading a public key in from DER format in memory (using d2i_PUBKEY), which is working fine for signature verification. However, the key in memory is only a public key (by design), and OpenSSL seems to be expecting a private key to be in the EVP_PKEY I send to EVP_OpenInit. How can I get OpenSSL to look at the public key in the EVP_PKEY and use it? From what I know of RSA, there's no reason this public key can't be used in a role a private key normally would be. I'd rather not have to create a second key pair, which seems redundant. I know it's not that hard to extract the key from the client executable, but I'm more concerned about eavesdropping third parties who will not have access to the client executable. -- Jeremy R. NovaWave Solutions __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: EVP_Open* with a public key
Thanks for your reply, first of all. I'm by no means an expert in cryptography (and obviously not on OpenSSL), and I'd appreciate any insight you can provide. On 24-Jul-09, at 7:14 PM, David Schwartz wrote: Jeremy R. wrote: I'm writing a client application that needs to verify some content from a server. I've generated an RSA key pair: the private key for the server and the public key for the client. Okay. I also would like the data to be encrypted, so I'm trying to use EVP_OpenInit on the receiving end to do my decryption. I'm reading a public key in from DER format in memory (using d2i_PUBKEY), which is working fine for signature verification. However, the key in memory is only a public key (by design), and OpenSSL seems to be expecting a private key to be in the EVP_PKEY I send to EVP_OpenInit. Think about it. For encryption to work, the intended recipient must know something that no attacker can possibly know. That will allow them, and only, to decrypt it. Yes, but what I have neglected to mention is that this information will be broadcast from my server to all instances of the client application. Therefore, anyone with access to a copy of the client application will be able to decrypt the message, period. How can I get OpenSSL to look at the public key in the EVP_PKEY and use it? From what I know of RSA, there's no reason this public key can't be used in a role a private key normally would be. I'd rather not have to create a second key pair, which seems redundant. It's not redundant. The second key pair would provide the intended recipient, the client, with something nobody else could know. It's not possible for encryption to work without that. Using the server's RSA key in reverse would produce something that was encrypted such that only public information was needed to decrypt it. What wold the point of that be? I think you misunderstand. My message format works like this: my application's data is already signed by the server's private key. As a result, it has a copy of the public key. The public and private keys are part of a key pair. From what I understand, RSA makes no distinction between which key is public and which is private, only that data encrypted with one can only be decrypted with the other. So I already have a key pair established, and the client is only aware of one key, which is currently used only for signature verification. Could I not also use that key to decrypt the symmetric message key? The corresponding key, which only the server has, and is currently termed the private key, is not known to the client. It is my understanding, then, that I should be able to use this key to encrypt my message, and that message will only be able to be decrypted by the client's key. Why should I need to create a second RSA key pair, when I already have a perfectly good 4096-bit key pair between the client and server applications? I know it's not that hard to extract the key from the client executable, but I'm more concerned about eavesdropping third parties who will not have access to the client executable. Can you prove that access to the client executable is the only way to get the server's public key? Is it really easier to do a full analysis on the security of your protocol to ensure that the server's public key is not revealed in any way? Because most existing protocols take no efforts whatsoever to protect public keys. The public key (the client's key) will only be distributed with the client application. In the event that the client's key is compromised, I may implement a re-keying mechanism that allows the server to give the clients a new key. But since this application will be broadcasting to all the clients and the overhead of key distribution and individually encrypting messages is unnecessary for my application, I don't need to be able to ensure that only one particular client can read it. I strongly advise you not to do something different from the way everyone else does it. That's very unlikely to produce a solution that is actually secure. DS __ 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: Using BIO_f_base64 on in-memory data
Never mind my question. Apparently the Base64 interpreter only accepts data if it's newline-terminated. Sorry for the bother. On 21-Jul-09, at 5:59 PM, Jeremy R. wrote: Hello: I'm trying to do something that should be fairly simple: read Base64- encoded data in memory block A and write it in decoded form to memory block B. I used the example here: http://www.openssl.org/docs/crypto/BIO_f_base64.html …as a starting point. When I try to read in-memory data, however, it simply vanishes. When I switch to either writing data in manually, or using a BIO pair, or using a BIO_s_mem, I can write data in (successfully, according to the return value of BIO_write), but when I read, it returns 0 or -1, depending on which approach I've used. When it's -1, BIO_should_retry() and BIO_should_read() both return true but BIO_should_write() returns false. I don't know where to go from here. I'm an OpenSSL newbie, and I'd appreciate any help you could offer. My Google searches haven't turned up anything useful. Best regards, -- Jeremy R. NovaWave Solutions__ 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
Read DER-encoded RSA public key in memory?
I'm trying to make a simple application which uses a 4096-bit RSA public key (encoded in DER format, statically compiled into the program itself. I generated this key with OpenSSL itself and I am able to do operations with it from the command-line. And I know I encoded it in the program correctly, because if I ask it to write TESTING_PUBLIC_KEY to disk, OpenSSL continues to accept it. However, when I try to use d2i_PublicKey to load it, it returns NULL. Anyone have any hints that might help me? My code is at http://pastebin.ca/1501265 and I'm compiling with VC++ (in C mode), for what it's worth. -- Jeremy R. NovaWave Solutions __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Read DER-encoded RSA public key in memory?
Thanks. I switched to using d2i_PUBKEY (it really is hard-coded, so I don't think there's a reason to use BIO – if I'm mistaken, please tell me) and it now returns a valid address in memory. On 20-Jul-09, at 4:59 PM, Mounir IDRASSI wrote: Hi, The public key in your source is encoded as a SubjectPublicKeyInfo, so you can't use d2i_PublicKey which only handles RSA public keys encoded in the PKCS#1 format. In your case, you have to use the function d2i_PUBKEY_bio to read your hard-coded key. Here is how you can do it using the same variables of your code : BIO* keyBio = BIO_new_mem_buf(TESTING_PUBLIC_KEY, sizeof(TESTING_PUBLIC_KEY)); public_key = d2i_PUBKEY_bio(keyBio, NULL); That's it! I hope this will help. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr Jeremy R. wrote: I'm trying to make a simple application which uses a 4096-bit RSA public key (encoded in DER format, statically compiled into the program itself. I generated this key with OpenSSL itself and I am able to do operations with it from the command-line. And I know I encoded it in the program correctly, because if I ask it to write TESTING_PUBLIC_KEY to disk, OpenSSL continues to accept it. However, when I try to use d2i_PublicKey to load it, it returns NULL. Anyone have any hints that might help me? My code is at http://pastebin.ca/1501265 and I'm compiling with VC+ + (in C mode), for what it's worth. __ 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
Best format for enveloped signed content
I'm writing an application which will receive messages which must be both enveloped and signed, and I'm looking for the best way to do this. Obviously, I can simply use EVP_Open* and EVP_Verify* in either order to do this, but I'm wondering if there's a good way to do this – ideally, I'd like to be able to use the openssl command-line utility to generate messages manually during development. I can't, however, seem to find any access to the EVP_Seal* methods in the openssl command-line utility, though signature is available through openssl dgst. Beyond that, I'm aware that PKCS#7 is used in S/MIME, and I've been told that using it is a good idea, but I can't seem to figure out why I should use it over simply doing the cryptographic operations – my code will not need to interoperate with anything else. If possible, I'd like control of the algorithms used, but I'd be willing to settle for default choices if they are reasonably secure. If I do have to do it manually, is there any convention as to which operation (signing or enveloping) should be done first? Is there a performance benefit to one approach? I apologize if this is a newbie question (I'm sure it is); I just didn't want to get started on this project in one format only to discover that I've made a dreadful mistake. Cheers, -- Jeremy R. NovaWave Solutions__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: General Question
They are two different network protocols which both implement cryptography. OpenSSL is primarily used by developers behind the scenes and not directly by users (though there is an openssl command-line tool that exposes many of OpenSSL's capabilities). I assume the command prompt feature you refer to is a remote shell, which is a built-in part of the SSH protocol (implemented by OpenSSH). While you could run a shell through an SSL tunnel, OpenSSL does not itself implement this. OpenSSL implements SSL/TLS, which is used to tunnel other protocols. A common example you may be aware of is banking sites which use HTTPS traffic. This is HTTP (web browsing, for the most part) traffic encrypted through an SSL/TLS tunnel. For this to work, both the client and the server must have an SSL/TLS implementation, of which OpenSSL is one (GnuTLS is another). For instance, the Apache webserver's mod_ssl uses OpenSSL to allow HTTPS traffic. If you don't already know what OpenSSL is, you probably do not want to use it directly. It sounds like you're looking for SSH, in which case, I'd direct you to OpenSSH. On 19-Jul-09, at 10:59 AM, Loke Foo Soon wrote: Hi All, I still new in openssl. May I know what different between openssh and openssl? They look a same. May I know how to use the openssl? Do they have any command prompt feature? Thanks -fsloke
Best format for enveloped signed content
I'm writing an application which will receive messages which must be both enveloped and signed, and I'm looking for the best way to do this. Obviously, I can simply use EVP_Open* and EVP_Verify* in either order to do this, but I'm wondering if there's a good way to do this – ideally, I'd like to be able to use the openssl command-line utility to generate messages manually during development. I can't, however, seem to find any access to the EVP_Seal* methods in the openssl command-line utility, though signature is available through openssl dgst. Beyond that, I'm aware that PKCS#7 is used in S/MIME, and I've been told that using it is a good idea, but I can't seem to figure out why I should use it over simply doing the cryptographic operations – my code will not need to interoperate with anything else. If possible, I'd like control of the algorithms used, but I'd be willing to settle for default choices if they are reasonably secure. If I do have to do it manually, is there any convention as to which operation (signing or enveloping) should be done first? Is there a performance benefit to one approach? I apologize if this is a newbie question (I'm sure it is); I just didn't want to get started on this project in one format only to discover that I've made a dreadful mistake. Cheers, -- Jeremy R. NovaWave Solutions__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
