Apologies for the name I’ve been sending under. I don’t represent Oracle of
course.
A temporary new MUA that isn’t quite doing what I expected.
Pauli
> On 8 May 2018, at 7:33 pm, Oracle wrote:
>
> Kurt wrote:
>
>> The comment about not hashing it is if you want to use the tool to
>> do entr
Kurt wrote:
> The comment about not hashing it is if you want to use the tool to
> do entropy estimation. Hashing it will not increase the entropy,
> but the estimation will be totally wrong.
> Passing the hashed data to the drbg as entropy input is fine if
> you already know how much entropy th
In message on Tue, 8 May 2018
12:26:59 -0400, Oracle said:
paul.dale> I can conform that it is measured in bits per sample size
paul.dale> (in this case bytes). The estimate is very low and this is
paul.dale> not a great source.
Note that this is on a fairly inactive machine, and it's not *on
I can conform that it is measured in bits per sample size (in this case bytes).
The estimate is very low and this is not a great source.
We can explore other options and I should be able to spare some time over ICMC
to assist. I’m not well versed in VMS though.
Pauli
> On 30 Apr 2018, at 12
We have not committed to being FIPS/NIST capable with our RNG this release. We
have committed to other things, and we seem to be falling behind on those.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listi
In message <20180501084317.ga32...@roeckx.be> on Tue, 1 May 2018 10:43:17
+0200, Kurt Roeckx said:
kurt> If you actually follow SP800-90B, you should make a theoretical
kurt> model of how much entropy you expect, and then use the tool
kurt> to verify that your model is correct.
E... look,
On Tue, May 01, 2018 at 06:09:13AM +0200, Richard Levitte wrote:
> In message <20180430162209.ga4...@roeckx.be> on Mon, 30 Apr 2018 18:22:09
> +0200, Kurt Roeckx said:
>
> kurt> On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
> kurt> >
> kurt> > So I'd like to have it confirmed
In message <20180501.060913.811991315461935857.levi...@openssl.org> on Tue, 01
May 2018 06:09:13 +0200 (CEST), Richard Levitte said:
levitte> Either way, this is quite discouraging, because this means that with
levitte> that estimate, I need to gather about 25 KiB of data to meet the
levitte> re
In message <20180430162209.ga4...@roeckx.be> on Mon, 30 Apr 2018 18:22:09
+0200, Kurt Roeckx said:
kurt> On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
kurt> >
kurt> > So I'd like to have it confirmed that I'm reading this right, that's
kurt> > about 0.08 entropy bits per 8 da
On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
>
> So I'd like to have it confirmed that I'm reading this right, that's
> about 0.08 entropy bits per 8 data bits? Or is it per data bit?
Per symbol, being 8 bits for what you provided.
> Depending on the interpretation, we eithe
In message <20180430.164908.1424770216194967097.levi...@openssl.org> on Mon, 30
Apr 2018 16:49:08 +0200 (CEST), Richard Levitte said:
levitte> In message <20180430.152609.587396153749337701.levi...@openssl.org> on
Mon, 30 Apr 2018 15:26:09 +0200 (CEST), Richard Levitte
said:
levitte>
levitte
In message <20180430.152609.587396153749337701.levi...@openssl.org> on Mon, 30
Apr 2018 15:26:09 +0200 (CEST), Richard Levitte said:
levitte> In message <20180430131000.ga25...@roeckx.be> on Mon, 30 Apr 2018
15:10:01 +0200, Kurt Roeckx said:
levitte>
levitte> kurt> The comment about not hashi
In message <20180430131000.ga25...@roeckx.be> on Mon, 30 Apr 2018 15:10:01
+0200, Kurt Roeckx said:
kurt> The comment about not hashing it is if you want to use the tool to
kurt> do entropy estimation. Hashing it will not increase the entropy,
kurt> but the estimation will be totally wrong.
kurt
On Mon, Apr 30, 2018 at 02:42:53PM +0200, Richard Levitte wrote:
> In message <20180424172439.ga8...@roeckx.be> on Tue, 24 Apr 2018 19:24:40
> +0200, Kurt Roeckx said:
>
> kurt> On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> kurt> > Like I think I mentioned a few days ago, I'
>pass all the data gathered (700-something bytes) through sha512 and
add the result to the pool.
I don't see a reason to hash it, just send it all
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/list
In message <20180424172439.ga8...@roeckx.be> on Tue, 24 Apr 2018 19:24:40
+0200, Kurt Roeckx said:
kurt> On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
kurt> > Like I think I mentioned a few days ago, I'm currently on a conference.
I'll take this up in more depth later this we
the CPU too much.
Pauli
--
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia
-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be]
Sent: Wednesday, 25 April 2018 3:25 AM
To: openssl-project@openssl.org
Subject: Re: [openssl
On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> Like I think I mentioned a few days ago, I'm currently on a conference. I'll
> take this up in more depth later this week.
>
> I have a question, though... Kurt said at some point that all that was needed
> on the VMS side was to
Like I think I mentioned a few days ago, I'm currently on a conference. I'll
take this up in more depth later this week.
I have a question, though... Kurt said at some point that all that was needed
on the VMS side was to collect data, the rest can be done elsewhere
(thankfully). However, I don
bject: Re: [openssl-project] Entropy seeding the DRBG
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all
> kinds of data that you can get out from the VMS kernel, most notably
> through a
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all
> kinds of data that you can get out from the VMS kernel, most notably
> through a system service called sys$getrmi()... there's a gazillion
> data points, a tre
On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> kurt> I wonder if it's useful to have a thread of VMS that collects
> kurt> such bits all the time, like the kernel is doing.
>
> I was pondering something like that, and it does make sense. That, or
> creating a generic device dr
In message <20180407174527.gc20...@roeckx.be> on Sat, 7 Apr 2018 19:45:28
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
kurt> > In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018
18:00:32 +0200, Kurt Roeckx said:
kurt> >
kurt> >
On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32
> +0200, Kurt Roeckx said:
>
> kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> kurt> > > Can I suggest you try something like
> ku
In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32
+0200, Kurt Roeckx said:
kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
kurt> > > Can I suggest you try something like
kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
>
> And yeah, sure, especially if all i
In message <8c39cdf4-a91e-4dfb-be67-6799e07d3...@akamai.com> on Tue, 3 Apr 2018
16:58:17 +, "Salz, Rich" said:
rsalz> >Please note that that 50% extra is only used for
rsalz> >instantiating the DRBG. On reseed we it only uses 256
rsalz> >bits.
Instantiating is exactly the proble
4. April 2018 15:09
> An: openssl-project@openssl.org
> Betreff: Re: [openssl-project] Entropy seeding the DRBG
>
> In message <122b3c36-21ad-4904-a692-351ade567...@akamai.com> on Wed, 4 Apr
> 2018 11:58:54 +, "Salz, Rich"
> said:
>
> rsalz> Is it expec
>Note that with a nonce, that'll be 192 bits, unless I'm thinking
wrong... But I agree with you, at least from a very practical point
of view.
I think using a nonce is needless. Use a personalization string (I used the
address of the new DRBG).
__
In message <122b3c36-21ad-4904-a692-351ade567...@akamai.com> on Wed, 4 Apr 2018
11:58:54 +, "Salz, Rich" said:
rsalz> Is it expected that the number of bits of seed must equal the
rsalz> number of bits in the key strength?
It is expected that the number of bits of entropy in the seed (the V
Is it expected that the number of bits of seed must equal the number of bits in
the key strength?
But at any rate, raising the seed size to 256 seems mildly tolerable, although
I would prefer to keep it at 128. Raising it to 384 is wrong.
___
opens
> -Ursprüngliche Nachricht-
> Von: openssl-project Im Auftrag von
> Salz, Rich
> Gesendet: Mittwoch, 4. April 2018 02:59
> An: openssl-project@openssl.org
> Betreff: Re: [openssl-project] Entropy seeding the DRBG
>
> If you say that AES256 needs CSPRNG seeding
If you say that AES256 needs CSPRNG seeding with 256 bits, then why doesn't RSA
2048 keygen need seed to be seeded with 2048 bits? I am not a cryptographer,
but I do not agree with this argument
algorithms with a security level of 256 bit in TLS (like AES-256-CTR),
so it is necessary tha
Since both pull requests mentioned by Richard were reviewed and approved
by me, I would to add a few remarks on those two pull requests:
Ad #5401: Switch the DRBGs from AES-128-CTR to AES-256-CTR
> The requirement change from 128 to 256 happened with this commit:
>
> commit 32bda2b2e4900308c
t@openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG
In message on Tue, 3 Apr 2018
12:52:50 +, "Salz, Rich" said:
rsalz> I had not realized that we just increased the "entropy"
rsalz> requirements by 50%, from 256 to 384. The original DRBG
rsalz>
>Please note that that 50% extra is only used for instantiating the
DRBG. On reseed we it only uses 256 bits.
True. And now we're finding that VMS won't work. And I bet there are other
systems that will also find this amount excessive.
>There is an alternative to that 50% extra
On Tue, Apr 03, 2018 at 12:52:50PM +, Salz, Rich wrote:
> I had not realized that we just increased the “entropy” requirements by 50%,
> from 256 to 384. The original DRBG submission that I did only required 128
> bits. I think that is wrong, and I think the PR that did it (#5503) should
>
In message on Tue, 3 Apr 2018
12:52:50 +, "Salz, Rich" said:
rsalz> I had not realized that we just increased the “entropy”
rsalz> requirements by 50%, from 256 to 384. The original DRBG
rsalz> submission that I did only required 128 bits. I think that is
rsalz> wrong, and I think the PR t
I had not realized that we just increased the “entropy” requirements by 50%,
from 256 to 384. The original DRBG submission that I did only required 128
bits. I think that is wrong, and I think the PR that did it (#5503) should be
reverted.
I am concerned that we are trying to meet requirements
39 matches
Mail list logo
