Re: openssl-users Digest, Vol 63, Issue 35
Thank you! That was the issue. Clay > On Feb 21, 2020, at 7:54 AM, openssl-users-requ...@openssl.org wrote: > > Message: 5 > Date: Fri, 21 Feb 2020 22:51:51 +1000 > From: Dr Paul Dale > To: openssl-users > Subject: Re: CRYPTO_secure_malloc_init() fails without error message > Message-ID: <9006f365-9206-490b-b3a4-f2814d77e...@oracle.com> > Content-Type: text/plain; charset="utf-8" > >> CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, OPENSSL_MIN_HEAP_SIZE); > > I?d strongly suggest not passing the same value in the second position. This > parameter sets the minimum block size that can be allocated in the secure > heap. The init call returns an error in this situation. Do this instead: > CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, 16); > > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia >
Re: Questions about using Elliptic Curve ciphers in OpenSSL
Nicola...my apologies for the typo... From: openssl-users on behalf of Jason Schultz Sent: Friday, February 21, 2020 1:05 PM To: Nicola Tuveri Cc: openssl-users Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL Nicole- This was very helpful, thank you for taking the time to respond. I was confused about the parameters files, I understand why they are not needed. Also, I should have been more clear, the creation of these cert/key pairs is strictly for testing purposes (and to give our users an easy way to test before they have their own certificate, signed by a CA). Thanks again. From: Nicola Tuveri Sent: Wednesday, February 19, 2020 9:42 PM To: Jason Schultz Cc: Kyle Hamilton ; openssl-users Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL I think there might be some confusion. The "parameters" files are a legacy from when cryptosystems using "custom" domains were not widely deprecated. Such parameter files were required for any instance of key generation, to make sure that a key was generated in the defined custom domain, and were part of any key serialization because in cryptosystems that define domain parameters a keypair is generally void of operational meaning if it isn't associated with a domain in which that keypair can be used to perform operations and also because when two or more peers are involved we need to make sure that exchanged keys belonged to the same domain in which we chose to operate. Nowadays the experts discourage "custom" domains (see e.g. RFC 8422), as they bring way more disadvantages than advantages, especially considering that the disadvantages include potential serious security pitfalls. Historically you needed to pregenerate a domain parameters file for ephemeral DH used in the key exchange part of the TLS handshake, because key generation is a relatively cheap operation, but generating the big random primes required for creating new domain parameters is a quite demanding process: this was the params file that was provided to the SSL/TLS backend and needed to be saved alongside keys and certificates. With ECDH, parameter generation for custom domains is even more involved, error prone, and the validation of custom parameters received from a peer is very expensive and littered with risks for the overall security if not done properly. That being said, recommending "use named curves" just means to use well-established and studied set of parameters that standardizing bodies deemed recommendable for secure use: this way both peers refer to a set of parameters with a given common name rather than explicit parameters, and the clients can trust the evaluation done by experts rather than having to verify the received parameters for complex mathematical properties. Now, to the commands in your email, it must be clear that there are a few cryptosystems involved in a generic TLS handshake: 1. key exchange: usually ephemeral ECDH 2. digital signature (to validate the handshake with the server credentials): commonly RSA, ECDSA or EdDSA (depending on the server key type) 3. digital signature (to validate the certificate where the CA states "this public key belongs to this subject"): commonly RSA, ECDSA or EdDSA (depending on the CA key type) (We should note that 3 does not necessarily require a `verify()` operation for every handshake, because both the issuer and the subject credentials are static, so a certificate for a server could be validated once and cached for later use). 1) Ephemeral ECDH generates a new keypair for every handshake, so the parties need to agree on which domain parameters to use. We negotiate named curves rather than explicit parameters, and that is what `status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");` does: both parties specify a list of supported curves, and one in common is picked (preference on multiple hits is an irrelevant detail here). So no need for a parameters file here, we use a list of names, and this is independent from the cryptosystem picked for the two digital signature operations. 2) The server needs to have its own keypair, this means a one-time-only keygen operation for which parameters are necessary if we pick ECDSA as the cryptosystem of our choice. You can do this using explicit parameters or a named curve, and the latter is preferred. In any case there is no need to store a parameters file after the key has been generated, as the key parameters are saved in the key serialization anyway, both for named and for custom curves. There is no harm in generating an intermediary params file, but it is superfluous, and also the fact that there is no need to create such a file should answer to your original question about where/how it is best to store the parameter file. To generate such a private key without the need for an intermediate params file you could run:
Re: Questions about using Elliptic Curve ciphers in OpenSSL
Nicole- This was very helpful, thank you for taking the time to respond. I was confused about the parameters files, I understand why they are not needed. Also, I should have been more clear, the creation of these cert/key pairs is strictly for testing purposes (and to give our users an easy way to test before they have their own certificate, signed by a CA). Thanks again. From: Nicola Tuveri Sent: Wednesday, February 19, 2020 9:42 PM To: Jason Schultz Cc: Kyle Hamilton ; openssl-users Subject: Re: Questions about using Elliptic Curve ciphers in OpenSSL I think there might be some confusion. The "parameters" files are a legacy from when cryptosystems using "custom" domains were not widely deprecated. Such parameter files were required for any instance of key generation, to make sure that a key was generated in the defined custom domain, and were part of any key serialization because in cryptosystems that define domain parameters a keypair is generally void of operational meaning if it isn't associated with a domain in which that keypair can be used to perform operations and also because when two or more peers are involved we need to make sure that exchanged keys belonged to the same domain in which we chose to operate. Nowadays the experts discourage "custom" domains (see e.g. RFC 8422), as they bring way more disadvantages than advantages, especially considering that the disadvantages include potential serious security pitfalls. Historically you needed to pregenerate a domain parameters file for ephemeral DH used in the key exchange part of the TLS handshake, because key generation is a relatively cheap operation, but generating the big random primes required for creating new domain parameters is a quite demanding process: this was the params file that was provided to the SSL/TLS backend and needed to be saved alongside keys and certificates. With ECDH, parameter generation for custom domains is even more involved, error prone, and the validation of custom parameters received from a peer is very expensive and littered with risks for the overall security if not done properly. That being said, recommending "use named curves" just means to use well-established and studied set of parameters that standardizing bodies deemed recommendable for secure use: this way both peers refer to a set of parameters with a given common name rather than explicit parameters, and the clients can trust the evaluation done by experts rather than having to verify the received parameters for complex mathematical properties. Now, to the commands in your email, it must be clear that there are a few cryptosystems involved in a generic TLS handshake: 1. key exchange: usually ephemeral ECDH 2. digital signature (to validate the handshake with the server credentials): commonly RSA, ECDSA or EdDSA (depending on the server key type) 3. digital signature (to validate the certificate where the CA states "this public key belongs to this subject"): commonly RSA, ECDSA or EdDSA (depending on the CA key type) (We should note that 3 does not necessarily require a `verify()` operation for every handshake, because both the issuer and the subject credentials are static, so a certificate for a server could be validated once and cached for later use). 1) Ephemeral ECDH generates a new keypair for every handshake, so the parties need to agree on which domain parameters to use. We negotiate named curves rather than explicit parameters, and that is what `status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");` does: both parties specify a list of supported curves, and one in common is picked (preference on multiple hits is an irrelevant detail here). So no need for a parameters file here, we use a list of names, and this is independent from the cryptosystem picked for the two digital signature operations. 2) The server needs to have its own keypair, this means a one-time-only keygen operation for which parameters are necessary if we pick ECDSA as the cryptosystem of our choice. You can do this using explicit parameters or a named curve, and the latter is preferred. In any case there is no need to store a parameters file after the key has been generated, as the key parameters are saved in the key serialization anyway, both for named and for custom curves. There is no harm in generating an intermediary params file, but it is superfluous, and also the fact that there is no need to create such a file should answer to your original question about where/how it is best to store the parameter file. To generate such a private key without the need for an intermediate params file you could run: ~~~sh curve_name=prime256v1 privkey_file=mykeyout.pem openssl genpkey \ -algorithm EC -pkeyopt ec_paramgen_curve:$curve_name \ -pkeyopt ec_param_enc:named_curve \ -outform pem -out $privkey_file ~~~ Once you have a private key you could generate a certific
Re: CRYPTO_secure_malloc_init() fails without error message
> CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, OPENSSL_MIN_HEAP_SIZE);
I’d strongly suggest not passing the same value in the second position. This
parameter sets the minimum block size that can be allocated in the secure heap.
The init call returns an error in this situation. Do this instead:
CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE, 16);
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 21 Feb 2020, at 8:33 pm, Clay Shields wrote:
>
> Unfortunately that didn’t seem to be it. Updating my code to verify that I am
> root and running it:
>
> Output:
>
> The effective user id is 0
> The real user id is 0
> failed to init openssl secure heap the error may be (null)
>
> Code:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #define OPENSSL_MIN_HEAP_SIZE 65536
>
>
> int main(){
>
> SSL_load_error_strings();
> SSL_library_init ();
> OpenSSL_add_all_algorithms ();
>
> uid_t uid, euid;
> uid = getuid();
> euid = geteuid();
> printf("The effective user id is %d\n", (int) geteuid());
> printf("The real user id is %d\n", (int) getuid());
>
> // Initialize the OPENSSL secure heap space for key storage
> int ret = CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE,
> OPENSSL_MIN_HEAP_SIZE);
>
> if (ret == 0){
>printf("failed to init openssl secure heap the error may be %s\n",
> ERR_reason_error_string(ERR_get_error()));
> }
>
> }
>
>
>> On Feb 20, 2020, at 6:31 PM, Salz, Rich wrote:
>>
>> Are you running as root? If not, that's likely to be the problem.
>>
>
Re: CRYPTO_secure_malloc_init() fails without error message
Unfortunately that didn’t seem to be it. Updating my code to verify that I am
root and running it:
Output:
The effective user id is 0
The real user id is 0
failed to init openssl secure heap the error may be (null)
Code:
#include
#include
#include
#include
#include
#include
#include
#include
#define OPENSSL_MIN_HEAP_SIZE 65536
int main(){
SSL_load_error_strings();
SSL_library_init ();
OpenSSL_add_all_algorithms ();
uid_t uid, euid;
uid = getuid();
euid = geteuid();
printf("The effective user id is %d\n", (int) geteuid());
printf("The real user id is %d\n", (int) getuid());
// Initialize the OPENSSL secure heap space for key storage
int ret = CRYPTO_secure_malloc_init(OPENSSL_MIN_HEAP_SIZE,
OPENSSL_MIN_HEAP_SIZE);
if (ret == 0){
printf("failed to init openssl secure heap the error may be %s\n",
ERR_reason_error_string(ERR_get_error()));
}
}
> On Feb 20, 2020, at 6:31 PM, Salz, Rich wrote:
>
> Are you running as root? If not, that's likely to be the problem.
>
