RAND_DRBG futures
I’ve closed the vote. Five for, none against, the vote passes. RAND_DRBG will be absent in 3.0. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia
Re: RAND_DRBG
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
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
+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 <mailto:paul.d...@oracle.com>> 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 ><https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12509*pullrequestreview-455396828__;Iw!!GqivPVa7Brio!P_SYCN9POdf1ZT1I7v4h9G_oUTuels90DxKk1JmFkD7HcXsTPr9n0s3FX3XZZo_c2Q$>) >>> 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
> 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
Re: RAND_DRBG
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 > <mailto:paul.d...@oracle.com>> 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 >> <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12509*pullrequestreview-455396828__;Iw!!GqivPVa7Brio!P_SYCN9POdf1ZT1I7v4h9G_oUTuels90DxKk1JmFkD7HcXsTPr9n0s3FX3XZZo_c2Q$>) >> 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
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 > <https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/12509*pullrequestreview-455396828__;Iw!!GqivPVa7Brio!P_SYCN9POdf1ZT1I7v4h9G_oUTuels90DxKk1JmFkD7HcXsTPr9n0s3FX3XZZo_c2Q$>) > 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 >
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
[openssl-project] Merge conflicts caused by pull request #5462 - Publish the RAND_DRBG API
Hi, in a few hours I will merge pull request #5462 - Publish the RAND_DRBG API This pull request removes 14 public symbols (symbols RAND_POOL_*, numbers 4351 - 4364) and closes the gap by renumbering all following symbols. Anyone of you who as added new symbols to libcrypto.num in his pull request will encounter a merge-conflict during his next rebase. Don't be scared about the size of the conflict, there is a simple solution: accept all incoming changes (discarding yours) and then run 'make update' again. HTH, Matthias ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
