Re: RAND_DRBG

2020-07-27 Thread Dr Paul Dale
So far a universal voice for removal of the DRBG_RAND APIs.
I’ll write up an OMC vote.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 27 Jul 2020, at 6:51 pm, Matt Caswell  wrote:
> 
> I'm ok with option 1 (but it will require a vote). I think the
> percentage of our user base that are using the existing API is
> sufficiently close to zero that we're not breaking our compatibility
> promises.
> 
> Matt
> 
> 
> On 27/07/2020 02:08, Dr Paul Dale wrote:
>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit
>> badly with the move to provider based infrastructure.
>> They are definitely being deprecated in master but without more, the
>> extra layer of indirection and additional complexity generating random
>> numbers will remain.
>> 
>> The option I see are:
>> 
>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking
>> change.
>> 2. Bypass RAND_DRBG and live with a breaking change (refer:
>> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
>> 3. Leave things as they currently are in master.
>> 
>> The first two are breaking changes and will require an OMC vote.
>> 
>> 
>> Some pertinent points:
>> 
>> 1. RAND_bytes will continue to work as is — this API is perfect for
>> almost everyone.
>> 2. The RAND_METHOD functionality remains — this allows wholesale
>> replacement of OpenSSL’s RNGs if desired.
>> 3. The name EVP_RAND is the working name and might change — this is not
>> relevant to this discussion.
>> 4. The RAND_DRBG APIs are unlikely to be widely used — they were
>> introduced in 1.1.1.  The two users I know of (Akamai and NCP) are both
>> fine with them being removed.
>> 
>> 
>> Thoughts anyone?
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 



Re: RAND_DRBG

2020-07-27 Thread Matt Caswell
I'm ok with option 1 (but it will require a vote). I think the
percentage of our user base that are using the existing API is
sufficiently close to zero that we're not breaking our compatibility
promises.

Matt


On 27/07/2020 02:08, Dr Paul Dale wrote:
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit
> badly with the move to provider based infrastructure.
> They are definitely being deprecated in master but without more, the
> extra layer of indirection and additional complexity generating random
> numbers will remain.
> 
> The option I see are:
> 
> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking
> change.
> 2. Bypass RAND_DRBG and live with a breaking change (refer:
> https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
> 3. Leave things as they currently are in master.
> 
> The first two are breaking changes and will require an OMC vote.
> 
> 
> Some pertinent points:
> 
> 1. RAND_bytes will continue to work as is — this API is perfect for
> almost everyone.
> 2. The RAND_METHOD functionality remains — this allows wholesale
> replacement of OpenSSL’s RNGs if desired.
> 3. The name EVP_RAND is the working name and might change — this is not
> relevant to this discussion.
> 4. The RAND_DRBG APIs are unlikely to be widely used — they were
> introduced in 1.1.1.  The two users I know of (Akamai and NCP) are both
> fine with them being removed.
> 
> 
> Thoughts anyone?
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 


Re: RAND_DRBG

2020-07-27 Thread Tomas Mraz
+1 for the removal

⁣Tomáš​

27. 7. 2020 4:58, 4:58, SHANE LONTIS  napsal/a:
>
>i.e.  Choose option (1)
>
>> On 27 Jul 2020, at 11:14 am, SHANE LONTIS 
>wrote:
>>
>> If this is not going to break 99% of users + it improves the
>interface + the replacement to achieve the same is a few lines of code
>and is likely to occur in one place in an app, then it seems reasonable
>to change it to me.
>>
>>
>>> On 27 Jul 2020, at 11:08 am, Dr Paul Dale > wrote:
>>>
>>> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and
>sit badly with the move to provider based infrastructure.
>>> They are definitely being deprecated in master but without more, the
>extra layer of indirection and additional complexity generating random
>numbers will remain.
>>>
>>> The option I see are:
>>>
>>> 1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a
>breaking change.
>>> 2. Bypass RAND_DRBG and live with a breaking change (refer:
>https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828
>)
>>> 3. Leave things as they currently are in master.
>>>
>>> The first two are breaking changes and will require an OMC vote.
>>>
>>>
>>> Some pertinent points:
>>>
>>> 1. RAND_bytes will continue to work as is — this API is perfect for
>almost everyone.
>>> 2. The RAND_METHOD functionality remains — this allows wholesale
>replacement of OpenSSL’s RNGs if desired.
>>> 3. The name EVP_RAND is the working name and might change — this is
>not relevant to this discussion.
>>> 4. The RAND_DRBG APIs are unlikely to be widely used — they were
>introduced in 1.1.1.  The two users I know of (Akamai and NCP) are both
>fine with them being removed.
>>>
>>>
>>> Thoughts anyone?
>>>
>>>
>>> Pauli
>>> --
>>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
>>> Phone +61 7 3031 7217
>>> Oracle Australia
>>>
>>



Re: API renaming

2020-07-27 Thread Tomas Mraz
It was backported to Fedora and RHEL openssl packages. But of course that's our 
problem and is not a blocker for the rename.

On the other hand KDFs and MACs being a class of algorithms similarly to 
ciphers and digests gives some argument why to keep the EVP prefix.

⁣Tomáš​

⁣Tomáš​

24. 7. 2020 9:46, 9:46, SHANE LONTIS  napsal/a:
>As @levitte pointed out - it was not back ported (not sure why I
>thought it was)
>
>> On 24 Jul 2020, at 5:40 pm, Dr. Matthias St. Pierre
> wrote:
>>
>> > I think the KDF and MAC got back ported also...
>>
>> In this case it would be no question that we should keep the names
>EVP_KDF and EVP_MAC.
>>
>>
>>   Dr. Matthias St.
>Pierre
>>
>> Senior Software Engineer
>> matthias.st.pie...@ncp-e.com 
>> Phone: +49 911 9968-0
>> www.ncp-e.com
>
>>
>> Follow us on: Facebook
>
>| Twitter
>
>| Xing
>
>| YouTube
>
>| LinkedIn
>
>>
>> Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 •
>90449 • Nuremberg
>> North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite
>501-25 • Clearwater, FL 33755
>>
>> Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate
>Dietrich
>> Registry Court: Lower District Court of Nuremberg
>> Commercial register No.: HRB 7786 Nuremberg, VAT identification No.:
>DE 133557619
>>
>> This e-mail message including any attachments is for the sole use of
>the intended recipient(s) and may contain privileged or confidential
>information. Any unauthorized review, use, disclosure or distribution
>is prohibited. If you are not the intended recipient, please
>immediately contact the sender by reply e-mail and delete the original
>message and destroy all copies thereof.
>>
>>



RE: RAND_DRBG

2020-07-27 Thread Dr. Matthias St. Pierre
> The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
> with the move to provider based infrastructure.

Actually, it is not the RAND_DRBG API itself (as it is in 1.1.1) which is 
messy. It’s the fact that part of its interface is very low level
and that the EVP_RAND interface tries to move away from that. In particular, in 
the future seed sources will be pluggable by chaining
the primary DRBG to an entropy source which is provided as a fetchable EVP_RAND 
interface, not by replacing some internal callbacks.
(Note however, that fetchable entropy sources,  in particular sources of low 
quality, are not implemented yet and won’t be implemented
in time for version 3.0. But as far as I’m concerned, I can wait for 3.1, since 
my company is still transitioning from 1.0.2 to 1.1.1. )

Moving to the new approach while at the same time having to retain 
compatibility to the old approach, that’s what is creating the mess
under the hood. Most notably, it’s the two functions RAND_DRBG_set_callbacks() 
and RAND_DRBG_set() which are creating the problems.
Pull Request #12509 attempts to untangle the two RNG interfaces by providing 
two unrelated triples of RNGs (option 2 in Pauli’s proposal),
an EVP_RAND triple and a RAND_DRBG triple. This does not work out well, as 
pointed out by me in [1]. There might be a variant of option (2)
however to fix the problem described in [1], which could provide better 
compatibility:

4. Offer legacy RAND_METHOD (e.g. RAND_drbg_method(), RAND_OpenSSL_legacy(), …) 
as an alternative to RAND_OpenSSL()

Anybody who currently uses the RAND_DRBG callback mechanism, could activate 
this legacy RAND_METHOD to switch from the new
EVP_RAND triple to the legacy RAND_DRBG triple of random generators, and their 
callbacks would continue to work as expected.

I still favour option (1), but (4) might be a reasonable compromise. It comes 
at a price, because both RAND_METHODs need to be fully
supported  and tested thoroughly.

Matthias


[1] https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828

From: openssl-project  On Behalf Of Dr 
Paul Dale
Sent: Monday, July 27, 2020 3:08 AM
To: openssl-project@openssl.org
Subject: RAND_DRBG

The RAND_DRBG (crypto/rand/drbg_lib) APIs are quite some mess and sit badly 
with the move to provider based infrastructure.
They are definitely being deprecated in master but without more, the extra 
layer of indirection and additional complexity generating random numbers will 
remain.

The option I see are:

1. Remove, rather than deprecate, RAND_DRBG in 3.0.  This is a breaking change.
2. Bypass RAND_DRBG and live with a breaking change (refer: 
https://github.com/openssl/openssl/pull/12509#pullrequestreview-455396828)
3. Leave things as they currently are in master.

The first two are breaking changes and will require an OMC vote.


Some pertinent points:

1. RAND_bytes will continue to work as is — this API is perfect for almost 
everyone.
2. The RAND_METHOD functionality remains — this allows wholesale replacement of 
OpenSSL’s RNGs if desired.
3. The name EVP_RAND is the working name and might change — this is not 
relevant to this discussion.
4. The RAND_DRBG APIs are unlikely to be widely used — they were introduced in 
1.1.1.  The two users I know of (Akamai and NCP) are both fine with them being 
removed.


Thoughts anyone?


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia