Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)
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)
> 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)
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)
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)
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)
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)
>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)
> > 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)
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)
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)
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)
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)
In message on Sun, 8 Apr 2018 12:24:08 +, "Salz, Rich" said: rsalz> >Yes, after what I all said previously, it's clear the code could rsalz> use improvements. I think at least Matthias and I assumed the code rsalz> about the minimum size was correct and that there was a minimum rsalz> requirement of 128 bit. rsalz> 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? rsalz> I deliberately stayed away from all RAND stuff after the rsalz> initial PR, because I didn't want to step on anyone else's toes rsalz> and "hog" the work. I knew others (including Kurt) were very rsalz> interested in this. rsalz> Who is going to ensure that we improve the code? All things considered, I think "we" will. There seems to be enough discussion going on among interested parties, and it does sound like we want to find a common ground. 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)
>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)
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)
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)
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)
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)
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)
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. 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)
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)
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)
On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote: > 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? The requirement is not to have it 128 bit. Just that it doesn't repeat as often as a 128 random number. You're most likely not going to instantiate it 2^64 times. As long as the combination is unique, it should be fine. (It does say that it needs to be at least 128 bit, but I think that's actually only in the case that you use a random number.) 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)
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)
> 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 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. 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. > 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. > - 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. >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? All the more reason to revert it. In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just plain wrong. ___ 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)
>Compliance with AES was also never a stated goal. Implicitly it was because (a) it's a standard algorithm and (b) MTI for TLS. But more importantly, *it didn't break anything.* ___ 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)
On Sat, Apr 07, 2018 at 05:07:02PM +, Salz, Rich wrote: > > > >NIST SP800-90A rev1 section 8.6.7 has: > > Compliance with this was never a stated goal of this release. So not > relevant. Compliance with AES was also never a stated goal. 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)
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)
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)
>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)
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)
>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)
On Sat, Apr 07, 2018 at 02:15:51PM +, Salz, Rich wrote: > 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? NIST SP800-90A rev1 section 8.6.7 has: | A nonce may be required in the construction of a seed during | instantiation in order to provide a security cushion to block | certain attacks. The nonce shall be either: | | a. A value with at least (security_strength/2) bits of entropy, or | b. A value that is expected to repeat no more often than a | (security_strength/2)-bit random string would be expected to repeat. | | Each nonce shall be unique to the cryptographic module in which | instantiation is performed, but need not be secret. When used, the | nonce shall be considered to be a critical security parameter. | | A nonce may be composed of one (or more) of the following | components (other components may also be appropriate): | 1. A random value that is generated anew for each nonce, using an | approved random bit generator. | 2. A timestamp of sufficient resolution (detail) so that it is | different each time it is used. | 3. A monotonically increasing sequence number, or | 4. A combination of a timestamp and a monotonically increasing | sequence number, such that the sequence number is reset when and | only when the timestamp changes. For example, a timestamp may show | the date but not the time of day, so a sequence number is appended | that will not repeat during a particular day. | | For case 1 above, the random value could be acquired from the same | source and at the same time as the entropy input. In this case, | the seed could be considered to be constructed from an | “extra strong” entropy input and the optional personalization | string, where the entropy for the entropy input is equal to or | greater than (3/2 security_strength) bits. | | For case 2 above, the timestamp must be trusted. A trusted | timestamp is generated and signed by an entity that is trusted | to provide accurate time information. Case 1 requires an approved random bit generator, which we don't have by default. Case 2 requires the timestamp to be trusted. I think that applies to case 4 too. This is also something we can't do by default. I think case 3 requires us keep a counter even after restarting the application, which seems unlikely that we will implement it. So by default we can't do any of them. But you can argue that we can do case 1, 2 and 4 close enough. Case 1 is what we do now. I think we can do case 2 with something like gettimeofday() or clock_gettime() which I think provide plenty of resolution that it's unlikely to repeat. You can combine that with a counter to get case 4 if you really wanted. All you have to do is implement a get_nonce() function and set it by default. You can keep the behaviour that if no get_nonce function is set that it increases the entropy requirement. Kurt that ___ 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)
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