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
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
+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
> 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
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
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
