[openssl-project] Monthly Status Report (March)

2018-04-04 Thread Matt Caswell
As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Performed the 1.1.1 beta 1 (pre-3) release - Performed a security release for 1.1.0 and 1.0.2 - Carried out a number of different tasks around the

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Dr. Matthias St. Pierre
The internal state of the CTR-DRBG consists of a key K and a counter V (see figure 11 on page 48, which is the page before table 3). This is the reason why it requires bits_of(K) + bits_of(V) = keysize + blocksize = 256 + 128 = 384 bits to initialize the internal state of the DRBG. But the

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Salz, Rich
>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).

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Richard Levitte
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

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Salz, Rich
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. ___

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

2018-04-04 Thread Richard Levitte
I would like to have it more prominent. I mean, yes, there should probably be a known issues page, but I think that whatever we do, we should have a line close to the one liking to the 1.1.0h tarball. Why send people chasing for it on other pages? Also, some people are watching the source

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

2018-04-04 Thread Viktor Dukhovni
> On Apr 4, 2018, at 4:32 AM, Richard Levitte wrote: > > The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and > that's not what I'm here to talk about, but rather how we want to act > in cases like this. Do we make a new release? Do we create an > official

Re: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)

2018-04-04 Thread Richard Levitte
In message <20180404.103237.14102346559301117.levi...@openssl.org> on Wed, 04 Apr 2018 10:32:37 +0200 (CEST), Richard Levitte said: levitte> The attached report talks about CPP being required, but that's not the levitte> intention. Rather, this is an unnoticed mistake when