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