Re: crypt(3)

2020-01-17 Thread Dr Paul Dale
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

Re: crypt(3)

2020-01-17 Thread Dr Paul Dale
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

Re: crypt(3)

2020-01-17 Thread Richard Levitte
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

Re: crypt(3)

2020-01-17 Thread Kurt Roeckx
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

Re: crypt(3)

2020-01-17 Thread Matt Caswell
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

Re: crypt(3)

2020-01-17 Thread Tomas Mraz
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

Re: crypt(3)

2020-01-17 Thread Matt Caswell
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

Re: crypt(3)

2020-01-17 Thread Tomas Mraz
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,

Re: crypt(3)

2020-01-17 Thread Richard Levitte
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

Re: crypt(3)

2020-01-17 Thread Dr Paul Dale
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.