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
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 see
>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
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 archiv
I'd say where we have introduced a regression in the latest release it
wouldn't hurt to have a "known issues" page, or similar, which links to
commits or other information about how to patch or work around an issue.
I see no reason to make a new release unless we think the issue is
sufficiently se
> 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 patch? Do we make a
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 cherry-picking
levitt
The attached report talks about CPP being required, but that's not the
intention. Rather, this is an unnoticed mistake when cherry-picking
from master to 1.1.0.
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 ac
10 matches
Mail list logo
