Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message  on Sun, 8 Apr 2018 
21:51:52 +, "Dr. Matthias St. Pierre"  said:

Matthias.St.Pierre> > So I guess I'm still on track with wanting to specify a 
get_nonce
Matthias.St.Pierre> > function for VMS.  Speaking of that, got any ideas on how 
to hook that
Matthias.St.Pierre> > on appropriately, without butchering the current DRBG 
code?
Matthias.St.Pierre> 
Matthias.St.Pierre> Hold the line, I'm currently working on it...  

Cool, I'll hold.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Dr. Matthias St. Pierre]

> This also puts into question the no_df tests in test/drbgtest.c, how
> can we possibly, under the diverse conditions we're facing, assume to
> know if those tests will succeed or fail?

The no_df tests are o.k. as they are. In fact, OpenSSL supports using the DRBG 
with or without the derivation function. We ourselves, we are not using the 
no_df feature. But that does not mean we have to rip it out of our sources. 
It's there since FIPS 2.0 and it's implemented correctly. A possible use case 
would be the following: if an application has access to a true RNG then it 
could replace the get_entropy() callbacks and operate our DRBG without the 
derivation function. 



> So I guess I'm still on track with wanting to specify a get_nonce
> function for VMS.  Speaking of that, got any ideas on how to hook that
> on appropriately, without butchering the current DRBG code?

Hold the line, I'm currently working on it...  

Matthias



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sun, Apr 08, 2018 at 08:29:18PM +, Dr. Matthias St. Pierre wrote:
> Just for completeness sake: The entropy requirement is 256 and *not* 384 if a 
> derivation function is used.

But one way of implementing the nonce when a DF is not used, is to
also have 384 bit in that case, which is our current
implementation. If someone writes a default get_nonce function it
can be reduced to 256.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message  on Sun, 8 Apr 2018 
20:10:22 +, "Salz, Rich"  said:

rsalz> >The 384 comes straight out of SP800-90A, see the table 10.2.1.
rsalz>   
rsalz> I think we're getting close to needing a team vote on whether
rsalz> or not we want to follow SP800-90A for this release.

Hold that thought a moment more...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <83ae9015-a766-4497-a71d-d537837cf...@openssl.org> on Sun, 08 Apr 
2018 19:15:16 +0200, Richard Levitte  said:

levitte> 
levitte> 
levitte> Kurt Roeckx  skrev: (8 april 2018 17:36:27 CEST)
levitte> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
levitte> >> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
levitte> >> > > Because
levitte> >> > > - It is not clear we need to do so
levitte> >> > 
levitte> >> > >That we need to do what?
levitte> >> > 
levitte> >> > Do FIPS compliant random numbers in this release.
levitte> >> 
levitte> >> We will never have that in any release by default, like I already
levitte> >> stated a few times.
levitte> >> 
levitte> >> > Everything is a trade-off.  Please explain why you want AES256-CTR
levitte> >with a nonce, and why AES128-CTR with personalization (and/or a DF) is
levitte> >not sufficient.
levitte> >> 
levitte> >> RAND_DRBG_set() takes 2 parameters: type and flags.
levitte> >> 
levitte> >> Type can be:
levitte> >> - NID_aes_128_ctr
levitte> >> - NID_aes_192_ctr
levitte> >> - NID_aes_256_ctr
levitte> >> 
levitte> >> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
levitte> >> is required. When not using a DF the nonce is not used.
levitte> >> 
levitte> >> We always use a personalization string.
levitte> >> 
levitte> >> The requirements for not using a DF means that you need to use
levitte> >> "full entropy", which is even more strict then when using a DF.
levitte> >> Since we don't have a "full entropy" source, we can generate it
levitte> >> ourself, but it would require the double amount of entropy, so 512
levitte> >> bit. We have no code currently to do this, but there is an open
levitte> >> issue about it.
levitte> >
levitte> >This is actually wrong. When not using a DF, the seed length = 384
levitte> >for NID_aes_256_ctr. So we would need 768 bits of entropy if we
levitte> >don't have access to full entropy.
levitte> 
levitte> Wait what? This sounds nuts... Can you refer to something that backs 
your claim? 

Ah, hold on, that was without a DF, but we *are* using a DF by
default, which makes sense since we can't possibly assume that we have
an approved RBG or an entropy source that provides "full entropy",
hence, according to 10.2.1 in SP800-90Ar1:

| The use of the derivation function is optional if either an
| *approved* RBG or an entropy source provides full entropy output
| when entropy input is requested by the DRBG mechanism. Otherwise,
| the derivation function *shall* be used.

This also puts into question the no_df tests in test/drbgtest.c, how
can we possibly, under the diverse conditions we're facing, assume to
know if those tests will succeed or fail?

So I guess I'm still on track with wanting to specify a get_nonce
function for VMS.  Speaking of that, got any ideas on how to hook that
on appropriately, without butchering the current DRBG code?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Dr. Matthias St. Pierre]

Just for completeness sake: The entropy requirement is 256 and *not* 384 if a 
derivation function is used.

Please reread 
https://mta.openssl.org/pipermail/openssl-project/2018-April/000506.html

> -Ursprüngliche Nachricht-
> Von: openssl-project <openssl-project-boun...@openssl.org> Im Auftrag von 
> Salz, Rich
> Gesendet: Sonntag, 8. April 2018 22:10
> An: openssl-project@openssl.org
> Betreff: Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy 
> demand for this platform specifically (#5904)
> 
> >The 384 comes straight out of SP800-90A, see the table 10.2.1.
> 
> I think we're getting close to needing a team vote on whether or not we want 
> to follow SP800-90A for this release.
> 
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project


smime.p7s
Description: S/MIME cryptographic signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

>The 384 comes straight out of SP800-90A, see the table 10.2.1.
  
I think we're getting close to needing a team vote on whether or not we want to 
follow SP800-90A for this release.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Dr. Matthias St. Pierre]

> > Wait what? This sounds nuts... Can you refer to something that backs your 
> > claim?
> 
> The 384 comes straight out of SP800-90A, see the table 10.2.1.
> It's also in the code where we do:
> drbg->seedlen = keylen + 16;
> [...]
> if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
> [...]
> } else {
> drbg->min_entropylen = drbg->seedlen;
> 
> (With keylen == 32)
> 
> You'll also see that when not using a DF "full entropy" is needed,
> when using a DF it's not required.
> 
> A DRBG can only generate "full entropy" for the first security
> strength / 2 bits it generates after a reseed. This is at least
> covered in SP800-90C 10.4, but there are other places that mention
> this too. So you need to pull the double amount of entropy from
> your entropy source if it doesn't provide full entropy. This also
> requires to use of prediction resistance.
> 
> 
> Kurt


Even if your claim about the 768 bits of entropy is correct, it only proves 
that it was a good idea to make the derivation function the default in commit 
8164d91d1802e6173291dee50923cc60fcd3bf72.

Matthias


https://github.com/openssl/openssl/commit/8164d91d1802e6173291dee50923cc60fcd3bf72



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sun, Apr 08, 2018 at 07:15:16PM +0200, Richard Levitte wrote:
> 
> 
> Kurt Roeckx  skrev: (8 april 2018 17:36:27 CEST)
> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> >> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> >> > > Because
> >> > >- It is not clear we need to do so
> >> > 
> >> > >That we need to do what?
> >> > 
> >> > Do FIPS compliant random numbers in this release.
> >> 
> >> We will never have that in any release by default, like I already
> >> stated a few times.
> >> 
> >> > Everything is a trade-off.  Please explain why you want AES256-CTR
> >with a nonce, and why AES128-CTR with personalization (and/or a DF) is
> >not sufficient.
> >> 
> >> RAND_DRBG_set() takes 2 parameters: type and flags.
> >> 
> >> Type can be:
> >> - NID_aes_128_ctr
> >> - NID_aes_192_ctr
> >> - NID_aes_256_ctr
> >> 
> >> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
> >> is required. When not using a DF the nonce is not used.
> >> 
> >> We always use a personalization string.
> >> 
> >> The requirements for not using a DF means that you need to use
> >> "full entropy", which is even more strict then when using a DF.
> >> Since we don't have a "full entropy" source, we can generate it
> >> ourself, but it would require the double amount of entropy, so 512
> >> bit. We have no code currently to do this, but there is an open
> >> issue about it.
> >
> >This is actually wrong. When not using a DF, the seed length = 384
> >for NID_aes_256_ctr. So we would need 768 bits of entropy if we
> >don't have access to full entropy.
> 
> Wait what? This sounds nuts... Can you refer to something that backs your 
> claim? 

The 384 comes straight out of SP800-90A, see the table 10.2.1.
It's also in the code where we do:
drbg->seedlen = keylen + 16;
[...]
if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
[...]
} else {
drbg->min_entropylen = drbg->seedlen;

(With keylen == 32)

You'll also see that when not using a DF "full entropy" is needed,
when using a DF it's not required.

A DRBG can only generate "full entropy" for the first security
strength / 2 bits it generates after a reseed. This is at least
covered in SP800-90C 10.4, but there are other places that mention
this too. So you need to pull the double amount of entropy from
your entropy source if it doesn't provide full entropy. This also
requires to use of prediction resistance.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

Kurt Roeckx  skrev: (8 april 2018 17:36:27 CEST)
>On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
>> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
>> > > Because
>> > >  - It is not clear we need to do so
>> > 
>> > >That we need to do what?
>> > 
>> > Do FIPS compliant random numbers in this release.
>> 
>> We will never have that in any release by default, like I already
>> stated a few times.
>> 
>> > Everything is a trade-off.  Please explain why you want AES256-CTR
>with a nonce, and why AES128-CTR with personalization (and/or a DF) is
>not sufficient.
>> 
>> RAND_DRBG_set() takes 2 parameters: type and flags.
>> 
>> Type can be:
>> - NID_aes_128_ctr
>> - NID_aes_192_ctr
>> - NID_aes_256_ctr
>> 
>> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
>> is required. When not using a DF the nonce is not used.
>> 
>> We always use a personalization string.
>> 
>> The requirements for not using a DF means that you need to use
>> "full entropy", which is even more strict then when using a DF.
>> Since we don't have a "full entropy" source, we can generate it
>> ourself, but it would require the double amount of entropy, so 512
>> bit. We have no code currently to do this, but there is an open
>> issue about it.
>
>This is actually wrong. When not using a DF, the seed length = 384
>for NID_aes_256_ctr. So we would need 768 bits of entropy if we
>don't have access to full entropy.

Wait what? This sounds nuts... Can you refer to something that backs your 
claim? 

>
>
>Kurt
>
>___
>openssl-project mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> > > Because
> > >   - It is not clear we need to do so
> > 
> > >That we need to do what?
> > 
> > Do FIPS compliant random numbers in this release.
> 
> We will never have that in any release by default, like I already
> stated a few times.
> 
> > Everything is a trade-off.  Please explain why you want AES256-CTR with a 
> > nonce, and why AES128-CTR with personalization (and/or a DF) is not 
> > sufficient.
> 
> RAND_DRBG_set() takes 2 parameters: type and flags.
> 
> Type can be:
> - NID_aes_128_ctr
> - NID_aes_192_ctr
> - NID_aes_256_ctr
> 
> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
> is required. When not using a DF the nonce is not used.
> 
> We always use a personalization string.
> 
> The requirements for not using a DF means that you need to use
> "full entropy", which is even more strict then when using a DF.
> Since we don't have a "full entropy" source, we can generate it
> ourself, but it would require the double amount of entropy, so 512
> bit. We have no code currently to do this, but there is an open
> issue about it.

This is actually wrong. When not using a DF, the seed length = 384
for NID_aes_256_ctr. So we would need 768 bits of entropy if we
don't have access to full entropy.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

rsalz> My expectation was that the *maximum* would also be 128 bits.

>Not sure what you're saying there.  If the entropy acquisition
routines is over enthusiastic and delivers 277 bits of entropy, are
you saying it shouldn't be allowed to?

I meant to say that the requirement would only be 128 bits.  As to what happens 
if more is available, that's not relevant to what I was trying to say.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

>Yes, after what I all said previously, it's clear the code could
use improvements. I think at least Matthias and I assumed the code
about the minimum size was correct and that there was a minimum
requirement of 128 bit.
  
My expectation was that the *maximum* would also be 128 bits.  I deliberately 
stayed away from all RAND stuff after the initial PR, because I didn't want to 
step on anyone else's toes and "hog" the work.  I knew others (including Kurt) 
were very interested in this.

Who is going to ensure that we improve the code?


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

kurt> So then I suggest we support the syscalls on all platforms that
kurt> provide it.

Who takes responsibility for fixing this?


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sun, Apr 08, 2018 at 10:31:58AM +0200, Richard Levitte wrote:
> In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 
> +0200, Kurt Roeckx  said:
> 
> kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 
> 21:02:51 +0200, Kurt Roeckx  said:
> kurt> > 
> kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > kurt> > H...  case 4 shouldn't pose too much problems unless you 
> restart
> kurt> > kurt> > the application more than once every second or so (for a 1 
> second
> kurt> > kurt> > resolution).  On VMS, the system time is kept with 100 
> nanosecond
> kurt> > kurt> > granularity...  this doesn't mean that it's actually updated 
> every 100
> kurt> > kurt> > nanosecond, but the possibility is there when VMS runs on 
> fast enough
> kurt> > kurt> > hardware (a VAX is decidedly not in that range, Alpha has a 
> minimum
> kurt> > kurt> > update rate of 1ms, Itaniums are faster than most Alphas...). 
>  Either
> kurt> > kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 
> 64-bit
> kurt> > kurt> > counter to match the 128 bit nonce requirement, do I get that 
> right?
> kurt> > kurt> 
> kurt> > kurt> The requirement is not to have it 128 bit. Just that it doesn't
> kurt> > kurt> repeat as often as a 128 random number. You're most likely not
> kurt> > kurt> going to instantiate it 2^64 times. As long as the combination 
> is
> kurt> > kurt> unique, it should be fine.
> kurt> > 
> kurt> > "The requirements" depend on where you look.  Looking at the code, or
> kurt> > more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
> kurt> > this:
> kurt> > 
> kurt> > drbg->min_noncelen = drbg->min_entropylen / 2;
> kurt> > 
> kurt> > So the DRBG CTR code currently requires 128 bits minimum by default,
> kurt> > unconditionally.
> kurt> 
> kurt> The standard does not require this 128 bit. This 128 bit is only
> kurt> required for the random value. The example even has a nonce of 32
> kurt> bit.
> 
> So then maybe the code in drbg_ctr_init() shouldn't set such a high
> minimum when drbg->get_nonce is defined?  That, or RAND_DRBG_instantiate()
> shouldn't try to check against drbg->min_noncelen, i.e. the latter
> should only be used when drbg->get_nonce is undefined.

Yes, after what I all said previously, it's clear the code could
use improvements. I think at least Matthias and I assumed the code
about the minimum size was correct and that there was a minimum
requirement of 128 bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200, 
Kurt Roeckx  said:

kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 
21:02:51 +0200, Kurt Roeckx  said:
kurt> > 
kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > kurt> > H...  case 4 shouldn't pose too much problems unless you 
restart
kurt> > kurt> > the application more than once every second or so (for a 1 
second
kurt> > kurt> > resolution).  On VMS, the system time is kept with 100 
nanosecond
kurt> > kurt> > granularity...  this doesn't mean that it's actually updated 
every 100
kurt> > kurt> > nanosecond, but the possibility is there when VMS runs on fast 
enough
kurt> > kurt> > hardware (a VAX is decidedly not in that range, Alpha has a 
minimum
kurt> > kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  
Either
kurt> > kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 
64-bit
kurt> > kurt> > counter to match the 128 bit nonce requirement, do I get that 
right?
kurt> > kurt> 
kurt> > kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> > kurt> repeat as often as a 128 random number. You're most likely not
kurt> > kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> > kurt> unique, it should be fine.
kurt> > 
kurt> > "The requirements" depend on where you look.  Looking at the code, or
kurt> > more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
kurt> > this:
kurt> > 
kurt> > drbg->min_noncelen = drbg->min_entropylen / 2;
kurt> > 
kurt> > So the DRBG CTR code currently requires 128 bits minimum by default,
kurt> > unconditionally.
kurt> 
kurt> The standard does not require this 128 bit. This 128 bit is only
kurt> required for the random value. The example even has a nonce of 32
kurt> bit.

So then maybe the code in drbg_ctr_init() shouldn't set such a high
minimum when drbg->get_nonce is defined?  That, or RAND_DRBG_instantiate()
shouldn't try to check against drbg->min_noncelen, i.e. the latter
should only be used when drbg->get_nonce is undefined.

I don't know enough to decide what's appropriate here...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Bernd Edlinger]

On 04/08/18 09:49, Kurt Roeckx wrote:
> On Sun, Apr 08, 2018 at 07:15:32AM +0200, Richard Levitte wrote:
>> In message <20180407185034.ga25...@roeckx.be> on Sat, 7 Apr 2018 20:50:35 
>> +0200, Kurt Roeckx  said:
>>
>> kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
>> kurt> > work is just plain wrong.
>> kurt>
>> kurt> So then I suggest we support the syscalls on all platforms that
>> kurt> provide it.
>>
>> I'm sorry, I'm lost.  "the syscalls"?  You started refering to
>> syscalls when discussing getrandom(), so I'm going to assume that it's
>> related, but I fail to understand how it's related to platforms that
>> break, and most specifically to VMS.  What "syscalls" do you expect?
> 
> This is not related to VMS. What I see as most likely to break
> going from 1.1.0 to 1.1.1 is reseeding in a chroot. This can be
> solved by using a system call instead of /dev/urandom if it's
> available.
> 
> 

You say /dev/urandom is accessible on startup but no longer after
the process calls chroot?

If that is the problem, maybe the device could be opened on startup
and just left open for later reseeding?


Bernd.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 
> +0200, Kurt Roeckx  said:
> 
> kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > H...  case 4 shouldn't pose too much problems unless you restart
> kurt> > the application more than once every second or so (for a 1 second
> kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
> kurt> > granularity...  this doesn't mean that it's actually updated every 100
> kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
> kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
> kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
> kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
> kurt> > counter to match the 128 bit nonce requirement, do I get that right?
> kurt> 
> kurt> The requirement is not to have it 128 bit. Just that it doesn't
> kurt> repeat as often as a 128 random number. You're most likely not
> kurt> going to instantiate it 2^64 times. As long as the combination is
> kurt> unique, it should be fine.
> 
> "The requirements" depend on where you look.  Looking at the code, or
> more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
> this:
> 
> drbg->min_noncelen = drbg->min_entropylen / 2;
> 
> So the DRBG CTR code currently requires 128 bits minimum by default,
> unconditionally.

The standard does not require this 128 bit. This 128 bit is only
required for the random value. The example even has a nonce of 32
bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > H...  case 4 shouldn't pose too much problems unless you restart
kurt> > the application more than once every second or so (for a 1 second
kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
kurt> > granularity...  this doesn't mean that it's actually updated every 100
kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
kurt> > counter to match the 128 bit nonce requirement, do I get that right?
kurt> 
kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> repeat as often as a 128 random number. You're most likely not
kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> unique, it should be fine.

"The requirements" depend on where you look.  Looking at the code, or
more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
this:

drbg->min_noncelen = drbg->min_entropylen / 2;

So the DRBG CTR code currently requires 128 bits minimum by default,
unconditionally.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407185034.ga25...@roeckx.be> on Sat, 7 Apr 2018 20:50:35 
+0200, Kurt Roeckx  said:

kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
kurt> > work is just plain wrong.
kurt> 
kurt> So then I suggest we support the syscalls on all platforms that
kurt> provide it.

I'm sorry, I'm lost.  "the syscalls"?  You started refering to
syscalls when discussing getrandom(), so I'm going to assume that it's
related, but I fail to understand how it's related to platforms that
break, and most specifically to VMS.  What "syscalls" do you expect?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> > Because
> > - It is not clear we need to do so
> 
> >That we need to do what?
> 
> Do FIPS compliant random numbers in this release.

We will never have that in any release by default, like I already
stated a few times.

> Everything is a trade-off.  Please explain why you want AES256-CTR with a 
> nonce, and why AES128-CTR with personalization (and/or a DF) is not 
> sufficient.

RAND_DRBG_set() takes 2 parameters: type and flags.

Type can be:
- NID_aes_128_ctr
- NID_aes_192_ctr
- NID_aes_256_ctr

The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
is required. When not using a DF the nonce is not used.

We always use a personalization string.

The requirements for not using a DF means that you need to use
"full entropy", which is even more strict then when using a DF.
Since we don't have a "full entropy" source, we can generate it
ourself, but it would require the double amount of entropy, so 512
bit. We have no code currently to do this, but there is an open
issue about it.

There are other reasons we want to use the DF by default:
- We might have entropy sources that provide less than 8 bit of
  entropy per byte.
- We still want to support RAND_add()

The reason for the 256 bit version is that there are people that
want more than the 128 bit security level. In fact, our default
cipher order has aes-256 first. And I still read current
recommendations to use aes-256. I also read that the aes_128_ctr
DRBG might not even provide the 128 bit level, but something
much lower.


> > But I think there is at least
> enough code in there that you can write something so that the DRBG
> can be validated.
>
> But that wasn't a goal.  It *is* a goal of our next release.

So because it's not a goal to provide SM2/SM3/SM4, we don't care
that it's actually implemented properly? It's enough to just have
that name, and might do something totally different?

You also argue that because we agreed to TLS 1.3, that AES must
also be properly implemented? Doesn't it also require a proper
RNG? Or can we just call rand()?

> > - It is probably not appropriate in an API/ABI compatible 
> release
> > - It is not appropriate for a "silent change"
> 
> I'm not sure what you're talking about with the last 2 items. What
> changes are you talking about?
> 
> The fact that 384 bits of seed are needed, when before it was 128.

The previous release was 256, not 128.

> >getrandom() when available avoids this a little. But glibc in
> Debian stable is only at glibc 2.24 while 2.25 is needed. I think
> we should consider having support for the syscall ourself. We
> should probably also add support for such functions on *BSD.
>   
> So this is now a break change for debian stable?

Stable has 1.1.0 (and 1.0.2) and will most likely stay on 1.1.0.
But people will want to use TLS 1.3, so I will at least provide it
in backports. And unless we add support for the syscall, it will
probably come with some warning.

>  All the more reason to revert it.

You mean remove the whole DRBG? Or the reseeding?

(The 384 vs 256 really doesn't have any effect on /dev/urandom not
being in a chroot.)

> In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just 
> plain wrong.

So then I suggest we support the syscalls on all platforms that
provide it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
> +0200, Kurt Roeckx  said:
> 
> kurt> | For case 2 above, the timestamp must be trusted. A trusted
> kurt> | timestamp is generated and signed by an entity that is trusted
> kurt> | to provide accurate time information.
> kurt> 
> kurt> Case 1 requires an approved random bit generator, which we don't
> kurt> have by default.
> kurt> 
> kurt> Case 2 requires the timestamp to be trusted. I think that applies
> kurt> to case 4 too. This is also something we can't do by default.
> 
> I'm not sure what you mean with "trusted"...

It's right there in the quoted text, it needs to be signed.

But I wonder how that it supposed to really work. If you want to
avoid a replay attack, does that mean you need to use a nonce? Do
we bootstrap problem?

> kurt> I think case 3 requires us keep a counter even after restarting
> kurt> the application, which seems unlikely that we will implement it.
> kurt> 
> kurt> So by default we can't do any of them. But you can argue that we
> kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.
> 
> H...  case 4 shouldn't pose too much problems unless you restart
> the application more than once every second or so (for a 1 second
> resolution).  On VMS, the system time is kept with 100 nanosecond
> granularity...  this doesn't mean that it's actually updated every 100
> nanosecond, but the possibility is there when VMS runs on fast enough
> hardware (a VAX is decidedly not in that range, Alpha has a minimum
> update rate of 1ms, Itaniums are faster than most Alphas...).  Either
> way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
> counter to match the 128 bit nonce requirement, do I get that right?

What is not clear to me is that all DRBGs (the 1+2N) need to have
a unique nonce or not. The 3 first are all most likely to be
instantiated very close to each other. It might be that the
requirement is the nonce for all 3 is different. If you combine
this with a counter (case 4), it's easy to do this on a per
process basis, even if the time is only updated once per second.

But maybe the requirement can be over multiple processes? I really
don't know enough about this.

> kurt> I think we can do case 2 with something like gettimeofday() or
> kurt> clock_gettime() which I think provide plenty of resolution
> kurt> that it's unlikely to repeat.
> kurt> 
> kurt> You can combine that with a counter to get case 4 if you really
> kurt> wanted.
> kurt> 
> kurt> All you have to do is implement a get_nonce() function and set
> kurt> it by default. You can keep the behaviour that if no get_nonce
> kurt> function is set that it increases the entropy requirement.
> 
> Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
> rand_vms.c, we're basically set...  but that means we need to
> implement a generic one as well, no?

It might be a little strange that the default is different on
different platforms, but I don't see why that should be a problem.
But having a generic one is probably more useful to a VMS specific
one.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 04:48:51PM +, Salz, Rich wrote:
> >Like I said in the post I just made, I see zero problems with having
> that requirement on systems that can support it.  I don't see why we
> must lower the bar for *everyone* just because we currently need to do
> so for VMS
>   
> Because
>   - It is not clear we need to do so

That we need to do what?

>   - We are not required to do FIPS level DRBG/CSPRNG this release

It's not because we don't have a requirement that it can be
validated, that we should only implement it half. There are
reasons for those requirements, and they are valid even if you
don't validate it.

There are things we will not be able to do by default, because the
OS does not provide what is needed. But I think there is at least
enough code in there that you can write something so that the DRBG
can be validated.

>   - It is probably not appropriate in an API/ABI compatible release
>   - It is not appropriate for a "silent change"

I'm not sure what you're talking about with the last 2 items. What
changes are you talking about?

What I think might come more as something that breaks things is
that we now periodically reseed. It's not good enough anymore to
have /dev/urandom available at the start and before you chroot, it
now also needs to be available after you chroot. Our use of
getrandom() when available avoids this a little. But glibc in
Debian stable is only at glibc 2.24 while 2.25 is needed. I think
we should consider having support for the syscall ourself. We
should probably also add support for such functions on *BSD.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

>NIST SP800-90A rev1 section 8.6.7 has:

Compliance with this was never a stated goal of this release.  So not relevant.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
+0200, Kurt Roeckx  said:

kurt> On Sat, Apr 07, 2018 at 02:15:51PM +, Salz, Rich wrote:
kurt> > I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
kurt> > 
kurt> > What should I do to force that issue?
kurt> 
kurt> NIST SP800-90A rev1 section 8.6.7 has:
kurt> | A nonce may be required in the construction of a seed during
kurt> | instantiation in order to provide a security cushion to block
kurt> | certain attacks. The nonce shall be either:
kurt> |
kurt> | a. A value with at least (security_strength/2) bits of entropy, or
kurt> | b. A value that is expected to repeat no more often than a
kurt> | (security_strength/2)-bit random string would be expected to repeat.
kurt> |
kurt> | Each nonce shall be unique to the cryptographic module in which
kurt> | instantiation is performed, but need not be secret. When used, the
kurt> | nonce shall be considered to be a critical security parameter.
kurt> |
kurt> | A nonce may be composed of one (or more) of the following
kurt> | components (other components may also be appropriate):
kurt> | 1. A random value that is generated anew for each nonce, using an
kurt> | approved random bit generator.
kurt> | 2. A timestamp of sufficient resolution (detail) so that it is
kurt> | different each time it is used.
kurt> | 3. A monotonically increasing sequence number, or
kurt> | 4. A combination of a timestamp and a monotonically increasing
kurt> | sequence number, such that the sequence number is reset when and
kurt> | only when the timestamp changes. For example, a timestamp may show
kurt> | the date but not the time of day, so a sequence number is appended
kurt> | that will not repeat during a particular day.
kurt> |
kurt> | For case 1 above, the random value could be acquired from the same
kurt> | source and at the same time as the entropy input. In this case,
kurt> | the seed could be considered to be constructed from an
kurt> | “extra strong” entropy input and the optional personalization
kurt> | string, where the entropy for the entropy input is equal to or
kurt> | greater than (3/2 security_strength) bits.
kurt> |
kurt> | For case 2 above, the timestamp must be trusted. A trusted
kurt> | timestamp is generated and signed by an entity that is trusted
kurt> | to provide accurate time information.
kurt> 
kurt> Case 1 requires an approved random bit generator, which we don't
kurt> have by default.
kurt> 
kurt> Case 2 requires the timestamp to be trusted. I think that applies
kurt> to case 4 too. This is also something we can't do by default.

I'm not sure what you mean with "trusted"...

kurt> I think case 3 requires us keep a counter even after restarting
kurt> the application, which seems unlikely that we will implement it.
kurt> 
kurt> So by default we can't do any of them. But you can argue that we
kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.

H...  case 4 shouldn't pose too much problems unless you restart
the application more than once every second or so (for a 1 second
resolution).  On VMS, the system time is kept with 100 nanosecond
granularity...  this doesn't mean that it's actually updated every 100
nanosecond, but the possibility is there when VMS runs on fast enough
hardware (a VAX is decidedly not in that range, Alpha has a minimum
update rate of 1ms, Itaniums are faster than most Alphas...).  Either
way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
counter to match the 128 bit nonce requirement, do I get that right?

kurt> I think we can do case 2 with something like gettimeofday() or
kurt> clock_gettime() which I think provide plenty of resolution
kurt> that it's unlikely to repeat.
kurt> 
kurt> You can combine that with a counter to get case 4 if you really
kurt> wanted.
kurt> 
kurt> All you have to do is implement a get_nonce() function and set
kurt> it by default. You can keep the behaviour that if no get_nonce
kurt> function is set that it increases the entropy requirement.

Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
rand_vms.c, we're basically set...  but that means we need to
implement a generic one as well, no?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

>Like I said in the post I just made, I see zero problems with having
that requirement on systems that can support it.  I don't see why we
must lower the bar for *everyone* just because we currently need to do
so for VMS
  
Because
- It is not clear we need to do so
- We are not required to do FIPS level DRBG/CSPRNG this release
- It is probably not appropriate in an API/ABI compatible release
- It is not appropriate for a "silent change"


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

Like I said in the post I just made, I see zero problems with having
that requirement on systems that can support it.  I don't see why we
must lower the bar for *everyone* just because we currently need to do
so for VMS

Cheers,
Richard

In message <116a311c-48b3-4181-9e68-b2fcc8d2d...@akamai.com> on Sat, 7 Apr 2018 
14:15:51 +, "Salz, Rich"  said:

rsalz> I would like to see this put on hold until we fix the ‘now requires 50% 
more random seeding’ issue.
rsalz> 
rsalz> What should I do to force that issue?
rsalz> 
rsalz> From: Richard Levitte 
rsalz> Reply-To: openssl/openssl
rsalz> 

rsalz> 
rsalz> Date: Saturday, April 7, 2018 at 7:36 AM
rsalz> To: openssl/openssl 
rsalz> Cc: Subscribed 
rsalz> Subject: [openssl/openssl] VMS: lower the entropy demand for this 
platform specifically (#5904)
rsalz> 
rsalz> Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
rsalz> bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
rsalz> bits for the nonce demands 384 bits of entropy. Obviously, this makes
rsalz> anything random related to fail on VMS.
rsalz> 
rsalz> The solution for now, until we get the VMS rand_pool_acquire_entropy()
rsalz> to deliver more entropy, is to lower the bar for VMS specifically,
rsalz> i.e. making the default scrambling cipher AES-128-CTR instead of
rsalz> AES-256-CTR.
rsalz> 
rsalz> Fixes #5849
rsalz> 
rsalz> 
---
rsalz> 
rsalz> You can view, comment on, or merge this pull request online at:
rsalz> 
rsalz> https://github.com/openssl/openssl/pull/5904
rsalz> 
rsalz> Commit Summary
rsalz> 
rsalz> * VMS: lower the entropy demand for this platform specifically
rsalz> 
rsalz> File Changes
rsalz> 
rsalz> * M include/openssl/rand_drbg.h (10)
rsalz> 
rsalz> Patch Links:
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.patch
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.diff
rsalz> 
rsalz> ―
rsalz> You are receiving this because you are subscribed to this thread.
rsalz> Reply to this email directly, view it on GitHub, or mute the thread.
rsalz> 
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Salz, Rich]

I would like to see this put on hold until we fix the ‘now requires 50% more 
random seeding’ issue.

What should I do to force that issue?

From: Richard Levitte 
Reply-To: openssl/openssl 

Date: Saturday, April 7, 2018 at 7:36 AM
To: openssl/openssl 
Cc: Subscribed 
Subject: [openssl/openssl] VMS: lower the entropy demand for this platform 
specifically (#5904)


Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
bits for the nonce demands 384 bits of entropy. Obviously, this makes
anything random related to fail on VMS.

The solution for now, until we get the VMS rand_pool_acquire_entropy()
to deliver more entropy, is to lower the bar for VMS specifically,
i.e. making the default scrambling cipher AES-128-CTR instead of
AES-256-CTR.

Fixes 
#5849


You can view, comment on, or merge this pull request online at:

  
https://github.com/openssl/openssl/pull/5904

Commit Summary

  *   VMS: lower the entropy demand for this platform specifically

File Changes

  *   M 
include/openssl/rand_drbg.h
 (10)

Patch Links:

  *   
https://github.com/openssl/openssl/pull/5904.patch
  *   
https://github.com/openssl/openssl/pull/5904.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project