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

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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  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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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)

2018-04-08 Thread 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