Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Michael Wojcik]

And there's no reason for it to do so, because it isn't needed. If you generate 
one TLS packet every nanosecond, it will take nearly six centuries to overflow, 
by which time the version of TLS you're using will have been deprecated and all 
security guarantees are moot anyway.

In general, most security experts recommend against keeping a TLS conversation 
open for years at a time.

Michael Wojcik
Distinguished Engineer, Micro Focus



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich via openssl-users
Sent: Thursday, March 09, 2017 05:49
To: openssl-users@openssl.org
Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

No, it does not do this automatically.

if the nounce _explicit overflows or overlaps , then does openssl code 
handles it (atleast by initiating renegotiation )?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Jakob Bohm]

On 10/03/2017 04:34, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jakob Bohm
Sent: Thursday, March 09, 2017 19:05
To: openssl-users@openssl.org
Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

First, note my original calculation was wrong - I was thinking the counter was 
64 bits. In fact the nonce is 64 bits, and the counter is 32. So even if you 
only generate one packet per millisecond, you could wrap in under 50 days.

Can you send a packet per millisecond? Let's assume Ethernet framing, TCP, and 
IPv4. That's 64 bytes of overhead. TLS adds around 45 bytes of overhead to each 
packet. I can't be bothered to check now, but let's assume you can send a TLS 
packet with no application data, so that's 109 bytes per packet. At one per 
millisecond that's 8.72e5 b/s, so network bandwith isn't a problem (we'll 
assume this is over a LAN). Can the receiver keep up? (We can't sustain the 
rate if the receiver's window keeps filling.) Let's hope so; the node's not 
much use if it can't keep up with its network interface. (Also assume we've 
disabled Nagle.)

Now, 50 days is still a rather long-lived conversation. Maybe we can do one or 
two orders of magnitude better. We're still fine on bandwidth (for a LAN), so 
should still be OK on the receiver's stack as well. OpenSSL should be able to 
verify and decrypt 100,000 messages a second on modern hardware, I'd think; 
I've never bothered to benchmark that, but it can certainly do the individual 
operations much faster.

So now we're down to about 11 hours. At this point we seem to have a legitimate 
concern; not for every application, but for some, certainly.

I haven't looked to see what the RFC says about AES with GCM combining and what 
measures implementations should take to avoid the counter wrapping. In any 
case, my apologies to Akshar Kanak. (And, of course, I may have bungled my 
back-of-the-envelope calculations again...)


But if the starting value is random, the number of increments
before overflow or wrap will be random too (and could
hypothetically, but rarely, be as little as 1).

It should be computed modulo 2**32 (i.e. as an unsigned 64-bit integer). It's 
not overflow or wrapping past the maximum value that would be a problem; it's 
wrapping all the way back around so a value is repeated.

But that's not what you asked, and doing circular mod 2**bitsize is
a good solution as long as you don't go full circle.

I note that the recently revealed CIA guidelines for using cryptography (part 
of Year Zero) say the counter should always start at 0. (The explicit nonce is 
supposed to avoid ever using the same IV twice with a given key in GCM.)

I assumed the counter started at 0 for each record and the 64 bit
value was the one incremented.


Anyway, I thought TLS records were limited to slightly more than
16K each, so the in-record block counter would not count very far.

Perhaps it's too late, or perhaps I'm just being dense, but I'm not sure what 
you're getting at with this.

RFC 5246 says the TLSv1.2 record sequence number is a 64-bit value, that it 
starts at 0, and that if it would wrap you have to renegotiate (or start 
another six-hundred-year conversation, I guess).

Probably I'm just misunderstanding your point here though.

I seem to recall (I haven't looked at GCM details in years) that
the 128 bit value is incremented for each 128 bit block of plaintext,
plus once more for the mac-like tag.

From this I assumed the 32 bit field was the per-128-bit counter and the
64 bit field you asked about was the per-record counter.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] error making Private RSA

[william estrada]

I have been tiring to keep my posting to a minim but I am not getting
across  what I am looking to
fix.   And I have been getting reports that my source code is not
viewable.  In my Apache logs I see that some people have be using the
wrong link, they are tiring to use
"http://mt-umunhum-wireless.net/mt-umunhum-wireless.net/Sources;
This is wrong! use:
"http://mt-umunhum-wireless.net/Sources/rsa;
or
"216.173.131.138/Sources/rsa"

The most recent attempt is the rsapost.c with the output rsapost.txt

What I am attempting to do is:
1) generate a RSA key pair, working but always the same keys.
2) remove the public key, working
3) create a RSA structure with the public key, 4 methods, all fail.
4) use the public key to encrypt a sting, don't get here.
5) use the RSA pair to decrypt the string.

The code is not clean but here it is:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define OFF   "\x1B[0;0;0m"
#define DEFAULT   "\x1B[0;0;0m"
#define RED   "\x1B[1;31;40m"
#define BLUE  "\x1B[1;34;40m"
#define GREEN "\x1B[1;32;40m"
#define YELLOW"\x1B[1;33;40m"
#define CLEAR_EOL "\x1B[K"

void Dump( char *, int );
typedef unsigned char* UcharP;
typedef unsigned char  uchar;

#define Check_Key( Key, Action ) \
  if( RSA_check_key( Key ) != 1 )  { \
 printf( RED "%d %s Make Key Failed!\n" OFF, __LINE__, "(Key)" );\
 printf( RED "%s\n", \
 ERR_error_string( ERR_get_error(), NULL ) );\
 Action ;  } \
  else  {\
printf( BLUE "%d %s check key good\n" OFF , __LINE__, "Key" );  }

int main() {  // main()

  ERR_load_ERR_strings();

  RSA *My_RSA  = RSA_new();

  char Str[] = "1234567890";
  unsigned  char Out[1024];
  unsigned  char In[ 1024];
  int   RC, L, RSA_Len;

  unsigned long Error = ERR_get_error();
  char  *MSG  = ERR_error_string( Error, NULL);
  const  char *MSG2   = ERR_reason_error_string( Error );
  char  *ErrStr[100];

  BIGNUM *bne = BN_new();
  BN_set_word( bne, RSA_F4 );

  RC = RSA_generate_key_ex( My_RSA, 2048, bne, NULL );
  BN_free( bne );

  Check_Key( My_RSA, "return 1" );

  L = strlen( Str );
  printf ( BLUE "String: %s" OFF, Str );
  Dump( Str, L );

  RSA *Pub_RSA = RSA_new();

  // Extract Key from RSA Key pair
  BIO * Key_Bio = BIO_new( BIO_s_mem() );

  RC = PEM_write_bio_RSAPublicKey(  Key_Bio, My_RSA );

  printf( BLUE  "%d RC: %d\n" OFF, __LINE__ );

  size_t Key_Len = BIO_pending( Key_Bio   );
  char  *Key = malloc(  Key_Len + 1   );
  RC = BIO_read(Key_Bio, Key, Key_Len );
  Key[ Key_Len ] = '\0';

  printf( BLUE  "%d RC: %d, Len: %d\n" OFF, __LINE__, RC, Key_Len );

  // Let's see the data
  printf( BLUE  "\nKey type %s\n" OFF, "Public" );
  Dump( (char*) Key, -Key_Len );

  // Now try to fill in to RSA using the BIO method
  BIO* bio = BIO_new( BIO_s_mem() );
   bio = BIO_new_mem_buf( (void*)Key, -1 ) ;

  // Load the RSA key from the BIO
  printf( "Method 1\n" );
  RSA* RSA1 = NULL;
  RSA1 = PEM_read_bio_RSA_PUBKEY( bio, NULL, NULL, NULL ) ;
  if( !RSA1 )
printf( RED
" ERROR: Could not load PUBLIC KEY!\n"
" PEM_read_bio_RSA_PUBKEY FAILED:\n %s\n" OFF,
ERR_error_string( ERR_get_error(), NULL ) ) ;

  else Check_Key( RSA1, ";" );

  printf( "Method 2\n" );
  RSA *RSA2 = RSA_new();
  BIO_new_mem_buf( (void*)Key, -1 ) ;
  RC = PEM_write_bio_RSA_PUBKEY( bio, RSA2 ) ;
  if( !RSA2 )
printf( RED
" ERROR: Could not load PUBLIC KEY!\n"
" PEM_write_bio_RSA_PUBKEY FAILED:\n %s\n" OFF,
ERR_error_string( ERR_get_error(), NULL ) ) ;

  else Check_Key( RSA2, ";" );

  // Try Bio method 3
  printf( OFF "Method 3\n" );
  RSA *RSA3  = RSA_new();
  BIO* Pem = BIO_new( BIO_s_mem() );
  BIO_puts( Pem, Key );
  ERR_print_errors( Pem );

  if( RSA3 )  Check_Key( RSA3, ";" );

  RC = PEM_write_bio_RSA_PUBKEY(  Pem, RSA3 );
  printf( OFF "BIO RC: %d\n", RC );

  if( RSA3 )  Check_Key( RSA3, ";" );

  // Now try to fill in to RSA using the EVP method

  printf( OFF "Method 4\n" );

  RSA *RSA4  = RSA_new();

  EVP_PKEY* EVP_PEM_Key;

  EVP_PKEY* EVP_Pub_Key = d2i_PUBKEY_bio( Pem, NULL);

  ERR_print_errors( Pem );

  if( EVP_Pub_Key == NULL ) {
 Error = ERR_get_error( );
 MSG   = (char*) ERR_reason_error_string( Error );
 printf( RED "EVP Error: %s" OFF "\n", MSG );  }
  else {
 RSA4 = EVP_PKEY_get1_RSA( EVP_Pub_Key );  }

  Check_Key( RSA4, "return 1;" );

  while(1)  {
if( RSA1  &&  RSA_check_key( RSA1 ) == 1 )  {
   Pub_RSA = RSA1;break;  }
if( RSA2  &&  RSA_check_key( RSA2 ) == 1 )  {
   Pub_RSA = RSA2;break;  }
if( RSA3  &&  RSA_check_key( RSA3 ) 

Re: [openssl-users] scripting creating a cert

[Jan Danielsson]

On 03/10/17 00:49, Robert Moskowitz wrote:
[---]
> Is there some 'simple' way to provide these answers?  Like with env
> variables?

   I tend do create response files (one response per line) and then
simply pipe to openssl:

   $ cat foo.params | openssl ...

   Just make sure openssl doesn't need any password inputs.

-- 
Kind regards,
Jan Danielsson

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

Re: [openssl-users] scripting creating a cert

[Robert Moskowitz]

Jan,

On 03/09/2017 08:06 PM, Jan Danielsson wrote:

On 03/10/17 00:49, Robert Moskowitz wrote:
[---]

Is there some 'simple' way to provide these answers?  Like with env
variables?

I tend do create response files (one response per line) and then
simply pipe to openssl:

$ cat foo.params | openssl ...


I will try a few things out with this.

thanks


Just make sure openssl doesn't need any password inputs.



It doesn't for this command.


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

Re: [openssl-users] scripting creating a cert

[Salz, Rich via openssl-users]

Yes there are easier ways to do this.  Set up a conf file and use it (via the 
-conf flag).  You can use env vars, set default values, and so on.  Look at the 
config manpages, https://www.openssl.org/docs/manmaster/man5/

For a fuller example, see https://www.openssl.org/~rsalz/pki.tgz
 

PS -- find me in Chicago and I can answer questions, Robert :)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] scripting creating a cert

[Robert Moskowitz]

I am creating self-signed certs with:

openssl req -new -outform PEM -out certs/$your_host_tld.crt -newkey 
rsa:2048 -nodes -keyout private/$your_host_tld.key -keyform PEM -days 
3650 -x509 -extensions v3_req


Where, for example:

your_host_tld=z9m9z.test.htt-consult.com

Thing is that this then prompts for a number of fields:

Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Is there some 'simple' way to provide these answers?  Like with env 
variables?


thanks


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

Re: [openssl-users] [EXTERNAL] Re: error making Private RSA

[Sands, Daniel]

First, to get intelligible text errors, replace your initial call with
ERR_load_crypto_strings().  The ERR_load_ERR_strings call doesn't even
seem to be documented, likely because it only loads the strings
associated with the ERR API, and you likely need PEM and BIO error
strings.  When I did this, the error message was "no start line" for
method 1.

Second, it seems to matter whether you use PEM_load_bio_RSA_PUBKEY vs
PEM_load_bio_RSAPublicKey.

Next, CheckKey will likely only work when the private key is also read
in.  Otherwise it segfaults.

As a side note, the [n]curses library would be more portable with
whatever terminal you run the program over.

As for method 4:
d2i_ and i2d_ are for DER formatted buffers.  You're writing out
as PEM format.  You need to read it back in as PEM format, as attempted
in some of the previous methods.  So it makes sense that this method
fails.

On Thu, 2017-03-09 at 15:01 -0800, william estrada wrote:
> I have been tiring to keep my posting to a minim but I am not getting
> across  what I am looking to
> fix.   And I have been getting reports that my source code is not
> viewable.  In my Apache logs I see that some people have be using the
> wrong link, they are tiring to use
> "http://mt-umunhum-wireless.net/mt-umunhum-wireless.net/Sources;
> This is wrong! use:
> "http://mt-umunhum-wireless.net/Sources/rsa;
> or
> "216.173.131.138/Sources/rsa"
> 
> The most recent attempt is the rsapost.c with the output rsapost.txt
> 
> What I am attempting to do is:
> 1) generate a RSA key pair, working but always the same keys.
> 2) remove the public key, working
> 3) create a RSA structure with the public key, 4 methods, all fail.
> 4) use the public key to encrypt a sting, don't get here.
> 5) use the RSA pair to decrypt the string.
> 
> The code is not clean but here it is:
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define OFF   "\x1B[0;0;0m"
> #define DEFAULT   "\x1B[0;0;0m"
> #define RED   "\x1B[1;31;40m"
> #define BLUE  "\x1B[1;34;40m"
> #define GREEN "\x1B[1;32;40m"
> #define YELLOW"\x1B[1;33;40m"
> #define CLEAR_EOL "\x1B[K"
> 
> void Dump( char *, int );
> typedef unsigned char* UcharP;
> typedef unsigned char  uchar;
> 
> #define Check_Key( Key, Action ) \
>   if( RSA_check_key( Key ) != 1 )  { \
>  printf( RED "%d %s Make Key Failed!\n" OFF, __LINE__, "(Key)" );\
>  printf( RED "%s\n", \
>  ERR_error_string( ERR_get_error(), NULL ) );\
>  Action ;  } \
>   else  {\
> printf( BLUE "%d %s check key good\n" OFF , __LINE__, "Key" );  }
> 
> int main() {  // main()
> 
>   ERR_load_ERR_strings();
> 
>   RSA *My_RSA  = RSA_new();
> 
>   char Str[] = "1234567890";
>   unsigned  char Out[1024];
>   unsigned  char In[ 1024];
>   int   RC, L, RSA_Len;
> 
>   unsigned long Error = ERR_get_error();
>   char  *MSG  = ERR_error_string( Error, NULL);
>   const  char *MSG2   = ERR_reason_error_string( Error );
>   char  *ErrStr[100];
> 
>   BIGNUM *bne = BN_new();
>   BN_set_word( bne, RSA_F4 );
> 
>   RC = RSA_generate_key_ex( My_RSA, 2048, bne, NULL );
>   BN_free( bne );
> 
>   Check_Key( My_RSA, "return 1" );
> 
>   L = strlen( Str );
>   printf ( BLUE "String: %s" OFF, Str );
>   Dump( Str, L );
> 
>   RSA *Pub_RSA = RSA_new();
> 
>   // Extract Key from RSA Key pair
>   BIO * Key_Bio = BIO_new( BIO_s_mem() );
> 
>   RC = PEM_write_bio_RSAPublicKey(  Key_Bio, My_RSA );
> 
>   printf( BLUE  "%d RC: %d\n" OFF, __LINE__ );
> 
>   size_t Key_Len = BIO_pending( Key_Bio   );
>   char  *Key = malloc(  Key_Len + 1   );
>   RC = BIO_read(Key_Bio, Key, Key_Len );
>   Key[ Key_Len ] = '\0';
> 
>   printf( BLUE  "%d RC: %d, Len: %d\n" OFF, __LINE__, RC, Key_Len );
> 
>   // Let's see the data
>   printf( BLUE  "\nKey type %s\n" OFF, "Public" );
>   Dump( (char*) Key, -Key_Len );
> 
>   // Now try to fill in to RSA using the BIO method
>   BIO* bio = BIO_new( BIO_s_mem() );
>bio = BIO_new_mem_buf( (void*)Key, -1 ) ;
> 
>   // Load the RSA key from the BIO
>   printf( "Method 1\n" );
>   RSA* RSA1 = NULL;
>   RSA1 = PEM_read_bio_RSA_PUBKEY( bio, NULL, NULL, NULL ) ;
>   if( !RSA1 )
> printf( RED
>   " ERROR: Could not load PUBLIC KEY!\n"
>   " PEM_read_bio_RSA_PUBKEY FAILED:\n %s\n" OFF,
>   ERR_error_string( ERR_get_error(), NULL ) ) ;
> 
>   else Check_Key( RSA1, ";" );
> 
>   printf( "Method 2\n" );
>   RSA *RSA2 = RSA_new();
>   BIO_new_mem_buf( (void*)Key, -1 ) ;
>   RC = PEM_write_bio_RSA_PUBKEY( bio, RSA2 ) ;
>   if( !RSA2 )
> printf( RED
>   " ERROR: Could not 

Re: [openssl-users] scripting creating a cert

[Robert Moskowitz]

Hi, Rich.

Fancy meeting you here.

On 03/09/2017 07:33 PM, Salz, Rich via openssl-users wrote:

Yes there are easier ways to do this.  Set up a conf file and use it (via the 
-conf flag).  You can use env vars, set default values, and so on.  Look at the 
config manpages, https://www.openssl.org/docs/manmaster/man5/


Not easy enough for me.  But I will have to read it some more.


For a fuller example, see https://www.openssl.org/~rsalz/pki.tgz


'Fuller' is putting it mildly.  :)


PS -- find me in Chicago and I can answer questions, Robert :)


Plan on it!

Bob

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

Re: [openssl-users] scripting creating a cert

[Viktor Dukhovni]

> On Mar 9, 2017, at 6:49 PM, Robert Moskowitz  wrote:
> 
> I am creating self-signed certs with:
> 
> openssl req -new -outform PEM -out certs/$your_host_tld.crt -newkey rsa:2048 
> -nodes -keyout private/$your_host_tld.key -keyform PEM -days 3650 -x509 
> -extensions v3_req
> 
> Where, for example:
> 
> your_host_tld=z9m9z.test.htt-consult.com
> 
> Thing is that this then prompts for a number of fields

The simplest solution is to set the subject DN explicitly on the command-line:

   $ umask 077 # avoid world-readable private keys
   $ openssl req -new -newkey rsa:2048 -nodes -keyout 
private/$your_host_tld.key \
-x509 -subj "/CN=$(uname -n)" -out certs/$your_host_tld.crt \
-days 3650 -extensions v3_req

Fore more advanced related approaches see:


https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh

-- 
Viktor.

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

Re: [openssl-users] scripting creating a cert

[Robert Moskowitz]

Viktor,

On 03/09/2017 08:17 PM, Viktor Dukhovni wrote:

On Mar 9, 2017, at 6:49 PM, Robert Moskowitz  wrote:

I am creating self-signed certs with:

openssl req -new -outform PEM -out certs/$your_host_tld.crt -newkey rsa:2048 
-nodes -keyout private/$your_host_tld.key -keyform PEM -days 3650 -x509 
-extensions v3_req

Where, for example:

your_host_tld=z9m9z.test.htt-consult.com

Thing is that this then prompts for a number of fields

The simplest solution is to set the subject DN explicitly on the command-line:

$ umask 077 # avoid world-readable private keys


Perhaps (no perhaps about it) this is old information, but I picked up 
that I needed:


chmod 640 for the private keys for Apache.  (and postfix and others use 
these certs; at least they are in their confs)



$ openssl req -new -newkey rsa:2048 -nodes -keyout 
private/$your_host_tld.key \
-x509 -subj "/CN=$(uname -n)" -out certs/$your_host_tld.crt \
-days 3650 -extensions v3_req

Fore more advanced related approaches see:

 
https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh


Looks like this is pointing me in the direction I want to go.  I will 
dig more into this approach.


thank you


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

Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Jakob Bohm]

But if the starting value is random, the number of increments
before overflow or wrap will be random too (and could
hypothetically, but rarely, be as little as 1).

Anyway, I thought TLS records were limited to slightly more than
16K each, so the in-record block counter would not count very far.

On 09/03/2017 16:26, Michael Wojcik wrote:


And there's no reason for it to do so, because it isn't needed. If you 
generate one TLS packet every nanosecond, it will take nearly six 
centuries to overflow, by which time the version of TLS you're using 
will have been deprecated and all security guarantees are moot anyway.


In general, most security experts recommend against keeping a TLS 
conversation open for years at a time.


Michael Wojcik
Distinguished Engineer, Micro Focus

*From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On 
Behalf Of *Salz, Rich via openssl-users

*Sent:* Thursday, March 09, 2017 05:49
*To:* openssl-users@openssl.org
*Subject:* Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit 
overflow


No, it does not do this automatically.

*if the nounce _explicit overflows or overlaps , then does openssl 
code handles it (atleast by initiating renegotiation )?*



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] scripting creating a cert

[Robert Moskowitz]

On 03/09/2017 08:53 PM, Viktor Dukhovni wrote:

On Mar 9, 2017, at 8:43 PM, Robert Moskowitz  wrote:


   $ umask 077 # avoid world-readable private keys

Perhaps (no perhaps about it) this is old information, but I picked up that I 
needed:

chmod 640 for the private keys for Apache.  (and postfix and others use these 
certs; at least they are in their confs)

I strive to avoid the private disclosure race of first creating
a world-readable file, and then trying to do a quick chmod before
the bad guys get around to opening it.  That's why I recommend the
umask approach.

You can adjust the umask to suit your needs.  With OpenSSL 1.1.0,
if I recall correctly "keyout" files and the like are automatically
opened mode "0600". Rich Salz, who wrote the CLI option processing
code for 1.1.0 will correct me, if my memory if faulty.  There are
still a lot of users with 1.0.2 or earlier, and OpenSSL cannot
always figure out which files end up having private keys in them,
so the umask approach is a good precaution to keep using.


And Rich and I sit down and talk about things all the time at IETF. This 
time we will have some other items to discuss.


And since this will go into a world-readable (eventually) howto, this is 
good advice that I will work on incorporating.


Thanks

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

Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Thursday, March 09, 2017 19:05
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

First, note my original calculation was wrong - I was thinking the counter was 
64 bits. In fact the nonce is 64 bits, and the counter is 32. So even if you 
only generate one packet per millisecond, you could wrap in under 50 days.

Can you send a packet per millisecond? Let's assume Ethernet framing, TCP, and 
IPv4. That's 64 bytes of overhead. TLS adds around 45 bytes of overhead to each 
packet. I can't be bothered to check now, but let's assume you can send a TLS 
packet with no application data, so that's 109 bytes per packet. At one per 
millisecond that's 8.72e5 b/s, so network bandwith isn't a problem (we'll 
assume this is over a LAN). Can the receiver keep up? (We can't sustain the 
rate if the receiver's window keeps filling.) Let's hope so; the node's not 
much use if it can't keep up with its network interface. (Also assume we've 
disabled Nagle.)

Now, 50 days is still a rather long-lived conversation. Maybe we can do one or 
two orders of magnitude better. We're still fine on bandwidth (for a LAN), so 
should still be OK on the receiver's stack as well. OpenSSL should be able to 
verify and decrypt 100,000 messages a second on modern hardware, I'd think; 
I've never bothered to benchmark that, but it can certainly do the individual 
operations much faster.

So now we're down to about 11 hours. At this point we seem to have a legitimate 
concern; not for every application, but for some, certainly.

I haven't looked to see what the RFC says about AES with GCM combining and what 
measures implementations should take to avoid the counter wrapping. In any 
case, my apologies to Akshar Kanak. (And, of course, I may have bungled my 
back-of-the-envelope calculations again...)

> But if the starting value is random, the number of increments
> before overflow or wrap will be random too (and could
> hypothetically, but rarely, be as little as 1).

It should be computed modulo 2**32 (i.e. as an unsigned 64-bit integer). It's 
not overflow or wrapping past the maximum value that would be a problem; it's 
wrapping all the way back around so a value is repeated.

I note that the recently revealed CIA guidelines for using cryptography (part 
of Year Zero) say the counter should always start at 0. (The explicit nonce is 
supposed to avoid ever using the same IV twice with a given key in GCM.)

> Anyway, I thought TLS records were limited to slightly more than
> 16K each, so the in-record block counter would not count very far.

Perhaps it's too late, or perhaps I'm just being dense, but I'm not sure what 
you're getting at with this.

RFC 5246 says the TLSv1.2 record sequence number is a 64-bit value, that it 
starts at 0, and that if it would wrap you have to renegotiate (or start 
another six-hundred-year conversation, I guess).

Probably I'm just misunderstanding your point here though.

Michael Wojcik 
Distinguished Engineer, Micro Focus 

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

Re: [openssl-users] scripting creating a cert

[Viktor Dukhovni]

> On Mar 9, 2017, at 8:43 PM, Robert Moskowitz  wrote:
> 
>>   $ umask 077 # avoid world-readable private keys
> 
> Perhaps (no perhaps about it) this is old information, but I picked up that I 
> needed:
> 
> chmod 640 for the private keys for Apache.  (and postfix and others use these 
> certs; at least they are in their confs)

I strive to avoid the private disclosure race of first creating
a world-readable file, and then trying to do a quick chmod before
the bad guys get around to opening it.  That's why I recommend the
umask approach.

You can adjust the umask to suit your needs.  With OpenSSL 1.1.0,
if I recall correctly "keyout" files and the like are automatically
opened mode "0600". Rich Salz, who wrote the CLI option processing
code for 1.1.0 will correct me, if my memory if faulty.  There are
still a lot of users with 1.0.2 or earlier, and OpenSSL cannot
always figure out which files end up having private keys in them,
so the umask approach is a good precaution to keep using.

-- 
Viktor.

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

Re: [openssl-users] [openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue

[Salz, Rich via openssl-users]

Already fixed.


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

Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Salz, Rich via openssl-users]

No, it does not do this automatically.

if the nounce _explicit overflows or overlaps , then does openssl code 
handles it (atleast by initiating renegotiation )?

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

[openssl-users] Openssl 1.0.2 stable SNAP 20170309 issue

[The Doctor]

Script started on Thu Mar  9 05:45:36 2017
root@doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # make

making all in crypto...
making all in crypto/objects...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/camellia...
making all in crypto/seed...
making all in crypto/modes...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/srp...
making all in crypto/store...
making all in crypto/cmac...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make 
libcrypto.so.1.0.0);  fi
`libcrypto.so.1.0.0' is up to date.
making all in engines...
echo 

making all in engines/ccgost...
making all in ssl...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make 
libssl.so.1.0.0);  fi
`libssl.so.1.0.0' is up to date.
making all in apps...
/usr/local/bin/clang39 -DMONOLITH -I.. -I../include  -fPIC -DOPENSSL_PIC 
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE 
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include 
-DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c enc.c -o enc.o
enc.c:93:5: error: use of undeclared identifier 'cipher'
cipher = EVP_get_cipherbyname(name->name);
^
enc.c:94:9: error: use of undeclared identifier 'cipher'
if (cipher == NULL ||
^
enc.c:95:31: error: use of undeclared identifier 'cipher'
(EVP_CIPHER_flags(cipher) & EVP_CIPH_FLAG_AEAD_CIPHER) != 0 ||
  ^
enc.c:96:29: error: use of undeclared identifier 'cipher'
EVP_CIPHER_mode(cipher) == EVP_CIPH_XTS_MODE)
^
4 errors generated.
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170309/apps
*** Error code 1

Stop.
make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170309
root@doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # exzit

exzit: Command not found.
root@doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # exit

exit

Script done on Thu Mar  9 05:46:27 2017

Please fix.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users