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 appropria
> 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
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 c
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 thoug
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,
gt; 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.
>
>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:
> > 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) {
>
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
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?
>> >
>>
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.
>
>
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 requireme
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
>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 bit
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-proj
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
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> > k
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> >
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 pr
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> S
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 seco
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
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 does
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 fe
> 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
vali
>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
http
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
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
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 fo
>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
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
>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
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
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.c
34 matches
Mail list logo