Could the people who work with distros confirm this default choice or suggest
what they use please?
Thanks,
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia
> On 18 Jan 2020, at 10:05 am, Dr Paul Dale wrote:
>
> I’ve
Okay, it looks like the consensus is option 3 — deprecate and forget.
As far as I can tell, they are only used (by us) in one place outside of
libcrypto, so that will deprecate as well.
Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle
Right. Such a KDF could be implemented elsewhere, as a separate project.
Cheers
Richard
Kurt Roeckx skrev: (17 januari 2020 21:35:00 CET)
>On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
>> I’ve got several choices:
>> Leave them public and unchanged — that is, don’t deprecate
On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> I’ve got several choices:
> Leave them public and unchanged — that is, don’t deprecate these two
> functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at
On 17/01/2020 10:42, Tomas Mraz wrote:
> On Fri, 2020-01-17 at 10:34 +, Matt Caswell wrote:
>>
>> On 17/01/2020 06:31, Dr Paul Dale wrote:
>>> 1. Leave them public and unchanged — that is, don’t deprecate
>>> these two
>>> functions yet.
>>> 2. Deprecate them and add KDFs to replace
On Fri, 2020-01-17 at 10:34 +, Matt Caswell wrote:
>
> On 17/01/2020 06:31, Dr Paul Dale wrote:
> > 1. Leave them public and unchanged — that is, don’t deprecate
> > these two
> > functions yet.
> > 2. Deprecate them and add KDFs to replace them.
> > 3. Deprecate them, leave them alone
On 17/01/2020 06:31, Dr Paul Dale wrote:
> 1. Leave them public and unchanged — that is, don’t deprecate these two
> functions yet.
> 2. Deprecate them and add KDFs to replace them.
> 3. Deprecate them, leave them alone and hope they go away painlessly at
> some point.
2 is really
On Fri, 2020-01-17 at 16:31 +1000, Dr Paul Dale wrote:
> In the deprecation efforts for 3.0, I’ve hit something in the DES
> code that I’d appreciate input on.
>
> There are two functions (DES_crypt and DES_fcrypt) which implement
> the old crypt(3) password algorithm. Once these are deprecated,
I don't really see a reason to actually *remove* them. Deprecation
should suffice.
Cheers,
Richard
On Fri, 17 Jan 2020 09:19:40 +0100,
Dr Paul Dale wrote:
>
>
> My experience with embedded systems is that crypt(3) is in the standard
> library and not accessed
> via OpenSSL. Apps/password
My experience with embedded systems is that crypt(3) is in the standard library
and not accessed via OpenSSL. Apps/password uses DES_crypt() and password
crackers used to use OpenSSL for performance reasons. Neither seems like a
huge deal. I.e. I can’t think of a good reason to keep them.
10 matches
Mail list logo