Re: SHA_CTX h0, h1, h2, h3, h4

2019-10-30 Thread Jakob Bohm via openssl-users

On 30/10/2019 04:04, ratheesh kannoth wrote:

Hi,

1. what are these h0h4 ?

2. How are they generated ?

3. Could you help to locate code in openssl ?

typedef struct SHAstate_st {
 SHA_LONG h0, h1, h2, h3, h4;
 SHA_LONG Nl, Nh;
 SHA_LONG data[SHA_LBLOCK];
 unsigned int num;
} SHA_CTX;

Thanks,,


Read the specification of the SHA-1 algorithm (either in the FIPS 180-1
standard or in a textbook).

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



Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Frederick Gotham
 wrote in
news:XnsAAF8BACC24C3Bfgotham@195.159.176.226: 

> Jochen Bern 
> wrote: 
> 
>> SSH logins from remote that fail
> 
> 
> This is my exact problem right now. My device has booted up and I
> can't SSH into it.But this doesn't entirely make sense since it should
> be getting random numbers from the TPM2 chip anyway.
 
 

And anyway this behaviour didn't come from deleting /dev/random, but rather 
from making the default generator inside OpenSSL always give 0 for a random 
byte.



Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Jochen Bern  wrote:

> SSH logins from remote that fail


This is my exact problem right now. My device has booted up and I can't SSH 
into it.But this doesn't entirely make sense since it should be getting 
random numbers from the TPM2 chip anyway.



Re: Remove All Software Generators

2019-10-30 Thread Jochen Bern
On 10/30/2019 04:19 PM, openssl-users-requ...@openssl.org digested:
> From: Frederick Gotham 
> To: openssl-users@openssl.org
> 
> I even tried deleting /dev/random and  /dev/urandom

... don't do that. The Linux kernel is both a provider and a consumer of
entropy, e.g., to randomize the TCP sequence numbers as it establishes
TCP connections on behalf of applications. Unless you go all the way and
add a TPM driver (as the only source of entropy) to *the kernel*, you
risk ending up with "good crypto" on the application layer but easily
hijacked connections, defeated stack randomization, SSH logins from
remote that fail, etc. etc..

Kind regards,
-- 
Jochen Bern
Systemingenieur

E  jochen.b...@binect.de
W  www.binect.de


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky  wrote:

> You should do in your engine the following:


Just so you know, I'm not a developer of the TPM2 engine for OpenSSL.

Of course though I can still go in and edit the code here and there.


> Implement the TPM-provided RAND_METHOD in the engine
> call ENGINE_set_RAND for RAND method in the engine bind fuction
> 
> and write a config file similar to
> 


Even if I do all that, there is still the possibility that OpenSSL might 
use its built-in generator (for example if my library fails to load).

So it seems I must get the built-in generator to either:
1) Always return 0
2) Call 'abort'







Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
On Wed, Oct 30, 2019 at 6:58 PM Frederick Gotham 
wrote:

> Dmitry Belyavsky  wrote
> in
> news:cadqlbz+jctu_yqiw9w-fyo0o56mqua2nri6helr6pggxqdh...@mail.gmail.com:
>
> > On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham
> >  wrote:
> >
> >> Dmitry Belyavsky 
> >> wrote:
> >>
> >> >> You still have the OpenSSL built-in RNG.
> >>
> >>
> >>
> >> Is there a simple compiler flag to remove this?
> >>
> >> Or do I need to go into the source code and stick a "return -1;"
> >> somewhere?
> >>
> >> No. Openssl will not work if you do not provide a valid RAND_METHOD
> >> except
> > a very minimal set of operations.
> >
>
>
> So I have to go into the source code and do the following?
>
> int RAND_bytes(unsigned char *buf, int num)
> {
> memset(buf,0,num);
> return 1;
> }
>
> I can either make this function fail (e.g. call 'abort'), or I can always
> make it return 0.
>
> What do you think?
>
> No. It just makes the RNG unsuitable for any purpose but does not help you.

You should do in your engine the following:

Implement the TPM-provided RAND_METHOD in the engine
call ENGINE_set_RAND for RAND method in the engine bind fuction

and write a config file similar to
=
openssl_conf = openssl_def
[ openssl_def ]
engines = engines_section
[ engines_section ]
cryptocom = my_section

[ my_section ]
engine_id = myengine.so
default_algorithms = RAND
=

-- 
SY, Dmitry Belyavsky


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky  wrote
in
news:cadqlbz+jctu_yqiw9w-fyo0o56mqua2nri6helr6pggxqdh...@mail.gmail.com: 

> On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham
>  wrote:
> 
>> Dmitry Belyavsky 
>> wrote: 
>>
>> >> You still have the OpenSSL built-in RNG.
>>
>>
>>
>> Is there a simple compiler flag to remove this?
>>
>> Or do I need to go into the source code and stick a "return -1;"
>> somewhere? 
>>
>> No. Openssl will not work if you do not provide a valid RAND_METHOD
>> except 
> a very minimal set of operations.
> 


So I have to go into the source code and do the following?

int RAND_bytes(unsigned char *buf, int num)
{
memset(buf,0,num);
return 1;
}

I can either make this function fail (e.g. call 'abort'), or I can always 
make it return 0.

What do you think?



Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
On Wed, Oct 30, 2019 at 6:39 PM Frederick Gotham 
wrote:

> Dmitry Belyavsky  wrote:
>
> >> You still have the OpenSSL built-in RNG.
>
>
>
> Is there a simple compiler flag to remove this?
>
> Or do I need to go into the source code and stick a "return -1;" somewhere?
>
> No. Openssl will not work if you do not provide a valid RAND_METHOD except
a very minimal set of operations.

-- 
SY, Dmitry Belyavsky


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky  wrote:

>> You still have the OpenSSL built-in RNG.



Is there a simple compiler flag to remove this?

Or do I need to go into the source code and stick a "return -1;" somewhere?



Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
On Wed, Oct 30, 2019 at 6:20 PM Frederick Gotham 
wrote:

> Dmitry Belyavsky  wrote
>
> >> /etc/ssl/openssl.cnf
> >
> > Yes, or any custom.
> > But the engine must provide the RAND_METHOD and set it as default.
> >
> >
>
>
>
> But if my TPM2 engine fails to load, then OpenSSL will just use the
> 'rdrand' engine.
>
> So my defense agains this is to rebuild OpenSSL with the flag
> OPENSSL_NO_RDRAND.
>

It means that you've disabled the RDRAND engine.


> After I rebuild OpenSSL, I can then remove my TPM2 engine so that there's
> no engine at all.
>
> I tried running OpenSSL at my commandline just now, and here's what I got:
>
> ~# openssl
> OpenSSL> engine
> (dynamic) Dynamic engine loading support
> OpenSSL> rand -hex 10
> f49ca711e3056cf9064a
> OpenSSL>
>
>
> Where is it it getting that random data from ? ? ? There's no engine and
> yet it can still get a random number! I even tried deleting /dev/random
> and
> /dev/urandom, but it somehow is still getting random data from somewhere!
> But where?
>
>
>
> You still have the OpenSSL built-in RNG.


-- 
SY, Dmitry Belyavsky


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky  wrote

>> /etc/ssl/openssl.cnf
>
> Yes, or any custom.
> But the engine must provide the RAND_METHOD and set it as default.
> 
> 



But if my TPM2 engine fails to load, then OpenSSL will just use the 
'rdrand' engine.

So my defense agains this is to rebuild OpenSSL with the flag 
OPENSSL_NO_RDRAND.

After I rebuild OpenSSL, I can then remove my TPM2 engine so that there's 
no engine at all.

I tried running OpenSSL at my commandline just now, and here's what I got:

~# openssl
OpenSSL> engine
(dynamic) Dynamic engine loading support
OpenSSL> rand -hex 10
f49ca711e3056cf9064a
OpenSSL>


Where is it it getting that random data from ? ? ? There's no engine and 
yet it can still get a random number! I even tried deleting /dev/random and 
/dev/urandom, but it somehow is still getting random data from somewhere! 
But where?





Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
On Wed, Oct 30, 2019 at 6:08 PM Frederick Gotham 
wrote:

> Dmitry Belyavsky  wrote:
>
>
> >> It can be done via the engine code and config.
>
>
> Do you mean
>
> /etc/ssl/openssl.cnf
>
> ?
>
Yes, or any custom.
But the engine must provide the RAND_METHOD and set it as default.


-- 
SY, Dmitry Belyavsky


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky  wrote: 


>> It can be done via the engine code and config.


Do you mean

/etc/ssl/openssl.cnf

?




Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
On Wed, Oct 30, 2019 at 6:00 PM Frederick Gotham 
wrote:

> Dmitry Belyavsky wrote:
>
> > Did you try to create your own RAND_METHOD and set it as default on
> > loading the engine?
>
>
> No, I didn't try that.
>
> Note that I'm only using the OpenSSL binary, I'm not interfacing with an
> API.
>
> It can be done via the engine code and config.


-- 
SY, Dmitry Belyavsky


Re: Remove All Software Generators

2019-10-30 Thread Frederick Gotham
Dmitry Belyavsky wrote:

> Did you try to create your own RAND_METHOD and set it as default on
> loading the engine?


No, I didn't try that.

Note that I'm only using the OpenSSL binary, I'm not interfacing with an 
API.




Re: Remove All Software Generators

2019-10-30 Thread Dmitry Belyavsky
Did you try to create your own RAND_METHOD and set it as default on loading
the engine?

On Wed, Oct 30, 2019 at 5:40 PM Frederick Gotham 
wrote:

>
> I'm working on Linux with a x86-64 CPU.
>
> I have a TPM2 chip, and so I want OpenSSL to do all of its encryption
> and random number generation through the TPM2 chip.
>
> In the event that the chip fails, I do NOT want there to be a backup
> system. I do NOT want any kind of software psuedorandom number generator
> nor any software encryption routines.
>
> The engine that I'm using for OpenSSL is "libtpm2tss.so". This engine
> library requires two more libraries, "libtss2-tcti-device.so" and
> "libtss2-tcti-mssim.so". (The former is for using the TPM2 chip, whereas
> the latter is a software simulator).
>
> As I don't want to have a simulator, I tried simply deleting the
> simulator library, but this caused linkage problems for the mother
> engine library. As an alternative, I made a new dummy library in which
> all of the functions return an error value, and I put this dummy library
> in the place of the simulator. This transplant went fine.
>
> It appears that OpenSSL will kick and scream and refuse to die not
> matter how hard you hit it. If I try to generate a random number like
> this:
>
> openssl rand -hex 8
>
> Then it seems it will try in this order:
>
> 1) The TPM2 chip
> 2) The software simulator of the TPM2 chip
> 3) The built-in RDRAND number
> 4) Another one that I can't find
>
> I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of
> the in-built engine. I have even done "rm /dev/random" and "rm
> /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I
> run openssl rand -hex 8.
>
> How on earth to get OpenSSL to simply give up? I simply cannot have it
> use anything other than my TPM2 chip.
>
> Frederick
>
>
>

-- 
SY, Dmitry Belyavsky


Remove All Software Generators

2019-10-30 Thread Frederick Gotham


I'm working on Linux with a x86-64 CPU.

I have a TPM2 chip, and so I want OpenSSL to do all of its encryption 
and random number generation through the TPM2 chip.

In the event that the chip fails, I do NOT want there to be a backup 
system. I do NOT want any kind of software psuedorandom number generator 
nor any software encryption routines.

The engine that I'm using for OpenSSL is "libtpm2tss.so". This engine 
library requires two more libraries, "libtss2-tcti-device.so" and 
"libtss2-tcti-mssim.so". (The former is for using the TPM2 chip, whereas 
the latter is a software simulator).

As I don't want to have a simulator, I tried simply deleting the 
simulator library, but this caused linkage problems for the mother 
engine library. As an alternative, I made a new dummy library in which 
all of the functions return an error value, and I put this dummy library 
in the place of the simulator. This transplant went fine.

It appears that OpenSSL will kick and scream and refuse to die not 
matter how hard you hit it. If I try to generate a random number like 
this:

openssl rand -hex 8

Then it seems it will try in this order:

1) The TPM2 chip
2) The software simulator of the TPM2 chip
3) The built-in RDRAND number
4) Another one that I can't find

I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of 
the in-built engine. I have even done "rm /dev/random" and "rm 
/dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I 
run openssl rand -hex 8.

How on earth to get OpenSSL to simply give up? I simply cannot have it 
use anything other than my TPM2 chip.

Frederick




Re: OpenSSL compilation errors in Windows

2019-10-30 Thread Matt Caswell



On 29/10/2019 11:55, Nagalakshmi V J wrote:
> Hi Matt,
> 
> Thank you so much for your response. Those mentioned APIs resolved my
> errors.
> 
> For the below code,
> 
>  return  SSL_get_session(pConnection) != NULL &&
>                 pConnection->session->session_id_length != 0;
> 
> Any reference for accessing session_id_length?
> https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_generate_session_id.html

You should use SSL_SESSION_get_id() to get hold of the length:

https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_get_id.html

Matt

> 
> Not sure if I can use the above link.
> 
> 
> /Thanks & Regards,/
> /Nagalakshmi V J/
> 
> *From:* Matt Caswell 
> *Sent:* 29 October 2019 10:47
> *To:* Nagalakshmi V J ;
> openssl-users@openssl.org 
> *Subject:* Re: OpenSSL compilation errors in Windows
>  
> ** This mail has been sent from an external source **
> 
> 
> On 29/10/2019 10:34, Nagalakshmi V J wrote:
>>
>> tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),
>>
>>  pGenerator->master_secret,sizeof(pGenerator->master_secret),
>>
>>  km,tmp,num);
> 
> It seems your code is replicating parts of libssl - which seems like a
> strange (and possibly dangerous) thing to do!
> 
>> Struct ssl_ctx_st {
>>
>> …
>>
>> constEVP_MD *md5;  /* For SSLv3/TLSv1 'ssl3-md5' */
>>
>> constEVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */
>>
>> …
>>
>> }
> 
> You really don't need to access these things. They're just cached
> references to the value returned by EVP_get_digestbyname("ssl3-md5") and
> EVP_get_digestbyname("ssl3-sha1"). So you can call those functions
> directly anyway.
> 
> Matt
> 
> =
> Please refer to https://northamerica.altran.com/email-disclaimer
> for important disclosures regarding this electronic communication.
> =


RE: OpenSSL compilation errors in Windows

2019-10-30 Thread Nagalakshmi V J
Hi Matt,

Any inputs on the below query?

Thanks and regards,
Nagalakshmi

From: Nagalakshmi V J
Sent: Tuesday, October 29, 2019 5:25 PM
To: Matt Caswell ; Nagalakshmi V J 
; openssl-users@openssl.org
Subject: Re: OpenSSL compilation errors in Windows

Hi Matt,

Thank you so much for your response. Those mentioned APIs resolved my errors.

For the below code,

 return  SSL_get_session(pConnection) != NULL &&
pConnection->session->session_id_length != 0;

Any reference for accessing session_id_length?
https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_generate_session_id.html

Not sure if I can use the above link.


Thanks & Regards,
Nagalakshmi V J

From: Matt Caswell mailto:m...@openssl.org>>
Sent: 29 October 2019 10:47
To: Nagalakshmi V J 
mailto:nagalakshm...@altran.com>>; 
openssl-users@openssl.org 
mailto:openssl-users@openssl.org>>
Subject: Re: OpenSSL compilation errors in Windows

** This mail has been sent from an external source **


On 29/10/2019 10:34, Nagalakshmi V J wrote:
>
> tls1_PRF(s->ctx->md5,s->ctx->sha1,buf,(int)(p-buf),
>
>  pGenerator->master_secret,sizeof(pGenerator->master_secret),
>
>  km,tmp,num);

It seems your code is replicating parts of libssl - which seems like a
strange (and possibly dangerous) thing to do!

> Struct ssl_ctx_st {
>
> ...
>
> constEVP_MD *md5;  /* For SSLv3/TLSv1 'ssl3-md5' */
>
> constEVP_MD *sha1; /* For SSLv3/TLSv1 'ssl3->sha1' */
>
> ...
>
> }

You really don't need to access these things. They're just cached
references to the value returned by EVP_get_digestbyname("ssl3-md5") and
EVP_get_digestbyname("ssl3-sha1"). So you can call those functions
directly anyway.

Matt
=
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=