Re: Blog post

[Ethan Rahn]

Hello Matt,

Love the blog post, and of course a hearty thanks to everyone who worked on
the project to get it to this point.

Is the plan still to continue with the FIPS 140-2 validation instead of
140-3? Apologies for the lack of a first party source but
https://www.leidos.com/insights/fips-140-and-common-criteria-industry-updates-march-2020
lists Sept 22, 2021 as the last day for FIPS 140-2 submissions. Is OpenSSL
3.0 going to be submitted by then?

Cheers,

Ethan

On Thu, Jun 17, 2021, 06:43 Matt Caswell  wrote:

> For anyone interested I've written a blog post to accompany the 3.0 beta
> 1 release. You can read it here:
>
> https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/
>
> Matt
>

Re: Poll on manpages

[Ethan Rahn]

Rich,

If no-one else tells you, keeping the docs up to date is amazing work and
thank you for it.

My general thought is that all docs should be consistent with one another
for ease of cross referncing and skimming and the manpages should follow
the same layout.

Cheers,

Ethan

On Tue, Jan 28, 2020 at 11:21 AM Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> The next release of OpenSSL splits the “help” for commands into sections,
> like this:
>
>
>
> ; ./apps/openssl rehash --help
>
> Usage: rehash [options] [directory...]
>
>
>
> General options:
>
> -helpDisplay this summary
>
> -h   Display this summary
>
> -compat  Create both new- and old-style hash links
>
> -old Use old-style hash to generate links
>
> -n   Do not remove existing links
>
>
>
> Output options:
>
> -v   Verbose output
>
>
>
> Parameters:
>
> directoryOne or more directories to process (optional)
>
>
>
> Should the order of options in the manpages follow this layout?  Should
> there be a blank line (in the SYNOPSIS section!) between the option
> sections?  Please take a look at
> https://github.com/openssl/openssl/pull/10885 which does this for
> s_client.  You can see just the changed file here:
> https://github.com/openssl/openssl/blob/71d8c19554a65cf0717f6b7e7b34849456e76888/doc/man1/openssl-s_client.pod.in
>
>
>
> Replies to me will be summarized for the list.  Thanks!
>
>
>

Re: [openssl-users] EVP_PKEY_set1_EC_KEY seems to not set something that EVP_PKEY_derive needs

[Ethan Rahn]

Wow,

That was quite the oversight of mine. That fixed the issue. Thanks so much,
I appreciate your patience in dealing with my confusion over the APIs!

Cheers,

Ethan

On Sat, Mar 11, 2017 at 12:28 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 11/03/17 18:38, Ethan Rahn wrote:
> >size_t sharedSecretLen = 0;
>
> Set this to sizeof(sharedSecret).
>
> >
> >// Now derive the Shared Secret
> >EVP_PKEY_CTX *ctx;
> >
> >ctx = EVP_PKEY_CTX_new(pkey, NULL);
> >if (!ctx){
> >   fprintf( stderr, "Failed to make EVP_PKEY ctx\n" );
> >   ERR_load_crypto_strings();
>
> This should be called once at the start of your program - *before* any
> calls that might generate an error.
>
> >if (EVP_PKEY_derive(ctx, sharedSecret, ) <= 0){
>
> From the EVP_PKEY_derive documentation:
>
> https://www.openssl.org/docs/man1.0.2/crypto/EVP_PKEY_derive.html
>
> "If key is not NULL then before the call the keylen parameter should
> contain the length of the key buffer, if the call is successful the
> shared secret is written to key and the amount of data written to keylen."
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] EVP_PKEY_set1_EC_KEY seems to not set something that EVP_PKEY_derive needs

[Ethan Rahn]

Hey Matt,

I'm using openssl-1.0.2j to do this.

After a lot of debugging and poking around, I realized that my initial
thoughts were not quite correct. Somewhere in trying to come up with an
example, I noticed that the problem actually appears to be the buffer I am
passing in..

If I use a char array, it will fail to derive the shared secret, if I use a
char* it will succeed. I'm not quite sure what is going on there, but I
have some code below that shows the issue:

static int deriveSharedSecret( EVP_PKEY *pkey, EVP_PKEY *peerkey,
   char *sharedSecretHex ){
   /*
* Generalized function to derive shared secret and return the hex
format of it.
*/
   unsigned char sharedSecret[ 4096 ] = {0};
   size_t sharedSecretLen = 0;

   // Now derive the Shared Secret
   EVP_PKEY_CTX *ctx;

   ctx = EVP_PKEY_CTX_new(pkey, NULL);
   if (!ctx){
  fprintf( stderr, "Failed to make EVP_PKEY ctx\n" );
  ERR_load_crypto_strings();
  ERR_print_errors(BIO_new_fp(stderr, BIO_NOCLOSE));
  return 0;
   }
   if (EVP_PKEY_derive_init(ctx) <= 0){
  fprintf( stderr, "Failed to init EVP_PKEY ctx\n" );
  ERR_load_crypto_strings();
  ERR_print_errors(BIO_new_fp(stderr, BIO_NOCLOSE));
  return 0;
   }
   if (EVP_PKEY_derive_set_peer(ctx, peerkey) <= 0) {
  fprintf( stderr, "Failed to set EVP_PKEY peer\n" );
  ERR_load_crypto_strings();
  ERR_print_errors(BIO_new_fp(stderr, BIO_NOCLOSE));
  return 0;
   }

   int secretLen = 2048;
   unsigned char *skey;

   /* Create the buffer */
   if(NULL == (skey = OPENSSL_malloc(secretLen))){
  fprintf( stderr, "Failed to malloc buffer for secret\n" );
  return;
   }

   /* Derive the shared secret */
   if(1 != (EVP_PKEY_derive(ctx, skey, ))){
  fprintf( stderr, "Failed to derive secret and place into buffer\n" );
  return;
   } else {
  fprintf( stderr, "Found the darn secret!\n" );
   }
   if (EVP_PKEY_derive(ctx, sharedSecret, ) <= 0){
  fprintf( stderr, "Failed to derive shared secret\n" );
  ERR_load_crypto_strings();
  ERR_print_errors(BIO_new_fp(stderr, BIO_NOCLOSE));
  return 0;
   } else {
  fprintf( stderr, "FOUND IT!\n" );
   }

   bin2hex( sharedSecret, sharedSecretHex, sharedSecretLen );
   return 1;
}



On Fri, Mar 10, 2017 at 1:44 PM, Matt Caswell <m...@openssl.org> wrote:

>
>
> On 10/03/17 20:58, Ethan Rahn wrote:
> > Hello Openssl-users,
> >
> > I'm trying to write some code that derives the shared secret for 2
> > elliptic curve keys ( i.e. does ECDH )
> >
> > I am doing the following to load up both the local and remote EC key (
> > code shown for local side ):
> >
> > EC_KEY* localEC = EC_KEY_new_by_curve_name( curveName );
> > EC_KEY_set_private_key( localEC, privateKeyLocal )
> > EC_KEY_set_public_key_affine_coordinates( localEC, publicXCoordLocal,
> > publicYCoordLocal )
> >
> > I check the return values for all of these, as well as EC_KEY_check_key
> > at the end. Everything returns non-zero, so I assume that it is good to
> > go. I then do the following to turn the EC_KEY into an EVP_PKEY for ECDH:
> >
> > pkey = EVP_PKEY_new();
> > EVP_PKEY_set1_EC_KEY( *pkey, localEC );
> >
> > The same is done for the remote EC, except that the private key is not
> > loaded up.
> >
> > Now this is where things get weird.
> >
> > I run code pretty similar to the example given here ( starting from
> > EVP_PKEY_CTX_new() since I already have the pkey and peerkey. (
> > https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman ) and
> > it fails on the call to EVP_PKEY_derive()without an error message. I
> > tried running into under gdb() and it gets to ecdh_check() before it's
> > unable to fill in the ecdh_data structure, i.e. it returns it as NULL.
> >
> > If I use the example code to generate the local EVP_PKEY with a random
> > set of points on the correct curve, then run the following line, the key
> > derivation will work with the parameters I read in:
> > ( in this example, pkey is as in the example code, i.e. generated
> > randomly. pkey2 is the one I made via EVP_PKEY_set1_EC_KEY )
> >
> > EVP_PKEY_set1_EC_KEY( pkey, EVP_PKEY_get1_EC_KEY( pkey2 ) );
> >
> > It would appear that there is something that EVP_PKEY_set1_EC_KEY is not
> > setting, or perhaps that I need to add, but I'm unclear what that would
> > be. Does anyone on this list have any ideas?
>
> Which version of OpenSSL are you using?
>
> Can you provide a simple reproducer of the problem?
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] EVP_PKEY_set1_EC_KEY seems to not set something that EVP_PKEY_derive needs

[Ethan Rahn]

Hello Openssl-users,

I'm trying to write some code that derives the shared secret for 2 elliptic
curve keys ( i.e. does ECDH )

I am doing the following to load up both the local and remote EC key ( code
shown for local side ):

EC_KEY* localEC = EC_KEY_new_by_curve_name( curveName );
EC_KEY_set_private_key( localEC, privateKeyLocal )
EC_KEY_set_public_key_affine_coordinates( localEC, publicXCoordLocal,
publicYCoordLocal )

I check the return values for all of these, as well as EC_KEY_check_key at
the end. Everything returns non-zero, so I assume that it is good to go. I
then do the following to turn the EC_KEY into an EVP_PKEY for ECDH:

pkey = EVP_PKEY_new();
EVP_PKEY_set1_EC_KEY( *pkey, localEC );

The same is done for the remote EC, except that the private key is not
loaded up.

Now this is where things get weird.

I run code pretty similar to the example given here ( starting from
EVP_PKEY_CTX_new() since I already have the pkey and peerkey. (
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman ) and it
fails on the call to EVP_PKEY_derive()without an error message. I tried
running into under gdb() and it gets to ecdh_check() before it's unable to
fill in the ecdh_data structure, i.e. it returns it as NULL.

If I use the example code to generate the local EVP_PKEY with a random set
of points on the correct curve, then run the following line, the key
derivation will work with the parameters I read in:
( in this example, pkey is as in the example code, i.e. generated randomly.
pkey2 is the one I made via EVP_PKEY_set1_EC_KEY )

EVP_PKEY_set1_EC_KEY( pkey, EVP_PKEY_get1_EC_KEY( pkey2 ) );

It would appear that there is something that EVP_PKEY_set1_EC_KEY is not
setting, or perhaps that I need to add, but I'm unclear what that would be.
Does anyone on this list have any ideas?

Much thanks,

Ethan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

[Ethan Rahn]

Scott, I just checked the CVE ID's on mitre, and as of now ( 11:18 AM PST
1/26/17 ) they are all listed as 'reserved' and don't have any information
about the issue. NVD shows the same information. In either case, it seems
like an extra hoop to jump through to have to go to a third party site to
find a commit #, when the third party chooses to release the information.

On Thu, Jan 26, 2017 at 10:53 AM, Scott Neugroschl <scot...@xypro.com>
wrote:

> The CVE itself contains the commit info.  Find it at cve.mitre.org
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Ethan Rahn
> *Sent:* Thursday, January 26, 2017 10:40 AM
> *To:* openssl-users@openssl.org
> *Subject:* [openssl-users] Should openssl publish the commit #'s that
> fixed each CVE?
>
>
>
> Hello,
>
>
>
> When looking a the latest security announcement, something that I notice
> is that it's hard to find the actual commits that fixed an issue. If you
> search git.openssl.org you can find some of them if they are mentioned in
> the change message, but it still requires some active effort.
>
>
>
> Would it be a good idea for openssl to publish the commit(s) that fixed
> each CVE? It would make it easier to see what changed, which is great for
>
> a.) backporting.
>
> b.) satisfying curiosity of armchair cryptographers.
>
> c.) better assessing an issue.
>
>
>
> Cheers,
>
>
>
> Ethan
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Should openssl publish the commit #'s that fixed each CVE?

[Ethan Rahn]

Hello,

When looking a the latest security announcement, something that I notice is
that it's hard to find the actual commits that fixed an issue. If you
search git.openssl.org you can find some of them if they are mentioned in
the change message, but it still requires some active effort.

Would it be a good idea for openssl to publish the commit(s) that fixed
each CVE? It would make it easier to see what changed, which is great for
a.) backporting.
b.) satisfying curiosity of armchair cryptographers.
c.) better assessing an issue.

Cheers,

Ethan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Seeking to understand difference in RSA key gen between X9.31 and FIPS 186-4

[Ethan Rahn]

Hey Openssl-User's,

I'm trying to understand the difference between how primes are generated in
RSA X9.31 ANSI standards ( which I don't have access to ) and FIPS 186-4 (
found here: http://csrc.nist.gov/groups/STM/cavp/documents/dss2/rsa2vs.pdf )

In the code at crypto/bn/bn_x931p.c::BN_X931_generate_prime_ex you can see
that X_p1 and X_p2 are set to be 101 bit long random numbers. The FIPS
186-4 standard specifies under Table B.1 that for a 1024 bit modulus, p1
and p2 must be greater than 100 bits. So that's fine. But for 2048 and 3072
bit modulii ( sp? ) the minimum bit length of p1 and p2 will not be met.

Granted, ANSI X9.31 was written a long time ago, so maybe they didn't cover
2048 and 3072 bit numbers at the time. The concern that I have is that this
code doesn't appear to be meeting the newest recommendations. I'm not
enough of a crypto enthusiast to understand what the consequences of this
are, but does anyone else have any insights? Is my understanding of this
even correct, in that the FIPS 186-4 standards are not being met?

( I'm also assuming here that since the NIST CAVP recommendations for RSA
link to the FIPS document that they are worth following, individual
opinions expressed on this mailing list over FIPS itself non-withstanding ).

Cheers,

Ethan
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Building an application with OpenSSL and FIPS support.

[Ethan Rahn]

Matt,

What part of the selftest fails? Can you step through it with a debugger?

Cheers,

Ethan

On Fri, Oct 7, 2016 at 10:56 AM, Matthew Heimlich 
wrote:

> I'm on RHEL7. I've got a very simple encryption/decryption program that
> works fine without FIPS support enabled, but fails when it is:
>
> #include 
> #include 
> #include 
> #include 
>
> void handleErrors(void)
> {
> ERR_print_errors_fp(stderr);
> abort();
> }
>
> int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char 
> *key,
> unsigned char *iv, unsigned char *ciphertext)
> {
>   EVP_CIPHER_CTX *ctx;
>
>   int len;
>
>   int ciphertext_len;
>
>   /* Create and initialise the context */
>   if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
>
>   /* Initialise the encryption operation. IMPORTANT - ensure you use a key
>* and IV size appropriate for your cipher
>* In this example we are using 256 bit AES (i.e. a 256 bit key). The
>* IV size for *most* modes is the same as the block size. For AES this
>* is 128 bits */
>   if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
> handleErrors();
>
>   /* Provide the message to be encrypted, and obtain the encrypted output.
>* EVP_EncryptUpdate can be called multiple times if necessary
>*/
>   if(1 != EVP_EncryptUpdate(ctx, ciphertext, , plaintext, plaintext_len))
> handleErrors();
>   ciphertext_len = len;
>
>   /* Finalise the encryption. Further ciphertext bytes may be written at
>* this stage.
>*/
>   if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, )) handleErrors();
>   ciphertext_len += len;
>
>   /* Clean up */
>   EVP_CIPHER_CTX_free(ctx);
>
>   return ciphertext_len;
> }
>
> int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key,
>   unsigned char *iv, unsigned char *plaintext)
> {
>   EVP_CIPHER_CTX *ctx;
>
>   int len;
>
>   int plaintext_len;
>
>   /* Create and initialise the context */
>   if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
>
>   /* Initialise the decryption operation. IMPORTANT - ensure you use a key
>* and IV size appropriate for your cipher
>* In this example we are using 256 bit AES (i.e. a 256 bit key). The
>* IV size for *most* modes is the same as the block size. For AES this
>* is 128 bits */
>   if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
> handleErrors();
>
>   /* Provide the message to be decrypted, and obtain the plaintext output.
>* EVP_DecryptUpdate can be called multiple times if necessary
>*/
>   if(1 != EVP_DecryptUpdate(ctx, plaintext, , ciphertext, ciphertext_len))
> handleErrors();
>   plaintext_len = len;
>
>   /* Finalise the decryption. Further plaintext bytes may be written at
>* this stage.
>*/
>   if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, )) handleErrors();
>   plaintext_len += len;
>
>   /* Clean up */
>   EVP_CIPHER_CTX_free(ctx);
>
>   return plaintext_len;
> }
>
> int main (void)
> {
>   /* Force FIPS initialization */
>   FIPS_mode_set(1);
>   /* Set up the key and iv. Do I need to say to not hard code these in a
>* real application? :-)
>*/
>
>   /* A 256 bit key */
>   unsigned char *key = (unsigned char *)"01234567890123456789012345678901";
>
>   /* A 128 bit IV */
>   unsigned char *iv = (unsigned char *)"01234567890123456";
>
>   /* Message to be encrypted */
>   unsigned char *plaintext =
> (unsigned char *)"The quick brown fox jumps over the lazy 
> dog";
>
>   /* Buffer for ciphertext. Ensure the buffer is long enough for the
>* ciphertext which may be longer than the plaintext, dependant on the
>* algorithm and mode
>*/
>   unsigned char ciphertext[128];
>
>   /* Buffer for the decrypted text */
>   unsigned char decryptedtext[128];
>
>   int decryptedtext_len, ciphertext_len;
>
>   /* Initialise the library */
>   ERR_load_crypto_strings();
>   OpenSSL_add_all_algorithms();
>   OPENSSL_config(NULL);
>
>   /* Encrypt the plaintext */
>   ciphertext_len = encrypt (plaintext, strlen ((char *)plaintext), key, iv,
> ciphertext);
>
>   /* Do something useful with the ciphertext here */
>   printf("Ciphertext is:\n");
>   BIO_dump_fp (stdout, (const char *)ciphertext, ciphertext_len);
>
>   /* Decrypt the ciphertext */
>   decryptedtext_len = decrypt(ciphertext, ciphertext_len, key, iv,
> decryptedtext);
>
>   /* Add a NULL terminator. We are expecting printable text */
>   decryptedtext[decryptedtext_len] = '\0';
>
>   /* Show the decrypted text */
>   printf("Decrypted text is:\n");
>   printf("%s\n", decryptedtext);
>
>   /* Clean up */
>   EVP_cleanup();
>   ERR_free_strings();
>
>   return 0;
> }
>
> As you can see, just the demo code with FIPS enabled. Without FIPS, my
> output is:
>
> Ciphertext is:
>  - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc...@.}F..
> 0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1S..9.p
> 0020 - 2c 

Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

[Ethan Rahn]

Is there a reason why you cannot build it from a controlled build
environment and record the hash of the final .so?

It seems that it would be pretty non-trivial if not impossible to pull a .o
file from a .so in the exact same format that it went in, such that you
could check the hash. Being able to check if a .c file is in the same state
in the .so afterwards seems pretty much impossible given all the things
that would change in the code with compiling and linking in between the .c
state and the final .so state.

On Mon, Mar 14, 2016 at 5:30 PM, Satya Das  wrote:

> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Digest MD5 forbidden in FIPS mode

[Ethan Rahn]

MD5 is not considered a safe function to use hence it is forbidden in FIPS
mode. Can you use a different hash function ( such as SHA-something ) for
your use case?

On Mon, Jan 18, 2016 at 4:43 PM, Marcos Bontempo  wrote:

> Hello,
>
> I wrote a C code which enter in FIPS mode with fips_mod_set(1).
>
> But, when I call MD5 functions after setting FIPS mode, I get this error:
>
> md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API
> call to digest MD5 forbidden in FIPS mode! Aborted.
>
> Does anybody know what is wrong? How can I correct it?
>
> Any tip will be very helpful,
> Thanks.
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] force to use /dev/random for openssl fips module

[Ethan Rahn]

xxiao,

have you changed the code to also increase the timeout and not try to use
other devices to get entropy? If /dev/random is blocking at the time, it
may run into issues trying to look for other sources of entropy than giving
up.

On Tue, Dec 8, 2015 at 8:25 PM, xxiao8  wrote:

> I don't know how critical is the DEVRANDOM for openssl-fips, in e_os.h I
> saw this:
> 
> #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
> 
> we have a hardware RNG that is feeding /dev/random via:
> 
> /sbin/rngd -r /dev/hwrng -W 4000
> 
> so the /dev/random will never block, I thus change e_os.h to force usage
> of /dev/random(per our fips code reviewer's request, who thinks I need
> change that for fips):
> 
> #define DEVRANDOM "/dev/random"
> 
> this looks fine, however I don't know if it's really the right thing to
> do, after this change my system starts to have issues(silent reboot),
> changing this line back everything runs normally.
>
> any help is appreciated.
>
> xxiao
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl FIPS uses /dev/urandom by default?

[Ethan Rahn]

xxiao,

Are you sure you can't modify that? My understanding of FIPS mode is that
you cannot modify the FIPS code canister, which entropy sources are not a
part of.

Cheers,

Ethan

On Thu, Nov 12, 2015 at 8:08 AM, xxiao8  wrote:

> in e_os.h I saw
> ==
> #ifndef DEVRANDOM
>
> /* set this to a comma-separated list of 'random' device files to try out.
>
> * My default, we will try to read at least one of these files */
>
> #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
>
> # endif
> ==
> this basically sets /dev/urandom as the default which really is not
> FIPS-friendly, is there a way to override this during compilation to set
> the default to /dev/random instead? I'm not supposed to modify the source
> code as it will invalidate openssl-FIPS certificate.
>
> Thanks,
> xxiao
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Need help understanding tradeoffs of "-dsaparam" in dhparam

[Ethan Rahn]

Hello,

I'm trying to understand the tradeoffs of using "-dsaparam" in the openssl
"dhparam" command. I know that it won't create a strong prime
, but I'm not understanding the
tradeoffs with that very well. The wikipedia page says that primes with the
strong property are not considered necessary by some cryptography experts,
but I don't know what the tradeoffs of using "-dsaparam" are. Please note
this is being used for a ( nginx-based ) SSL server if that helps provide
context.

I know that it is much faster. For generating a 2048-bit diffie-hellman
parameter using "-dsaparam" takes ~10 seconds vs. ~30 minutes for the
strong prime defaults on the server I'm testing it on.

The downside is not very clear to me however. I know the man pages say "DH
parameter generation with the -dsaparam option is much faster, and the
recommended exponent length is shorter, which makes DH key exchange more
efficient. Beware that with such DSA-style DH parameters, a fresh DH key
should be created for each use to avoid small-subgroup attacks that may be
possible otherwise." This isn't clear to me if each connection the SSL
server makes should use a different dsaparam based dhparam? Is there
another meaning here?

Any clarifications on what I should beware of when using -dsaparam and what
a "new use" is when knowing when to make fresh dh keys would be very
appreciated.

Thanks,

Ethan
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users