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)
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 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)
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 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)
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)
>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)
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)
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)
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)
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 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)
> > 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)
>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)
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)
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)
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)
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)
> 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)
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
