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 made the deprecation changes to the password application.
> 
> The default has been changed from crypt to the BSD MD5 algorithm.
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 18 Jan 2020, at 9:27 am, Dr Paul Dale > > wrote:
>> 
>> 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 Australia
>> 
>> 
>> 
>> 
>>> On 18 Jan 2020, at 6:53 am, Richard Levitte >> > wrote:
>>> 
>>> Right. Such a KDF could be implemented elsewhere, as a separate project.
>>> 
>>> Cheers
>>> Richard
>>> 
>>> 
>>> Kurt Roeckx mailto:k...@roeckx.be>> 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 these two
 functions yet.
> Deprecate them and add KDFs to replace them.
> Deprecate them, leave them alone and hope they go away painlessly at
 some point.
 
 I really see no point in adding something that we at the same time
 would like to remove. Just deprecate it.
 
 
 Kurt
>>> 
>>> -- 
>>> Richard by mobile
>> 
> 



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 Australia




> On 18 Jan 2020, at 6:53 am, Richard Levitte  wrote:
> 
> 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 these two
>> functions yet.
>>> Deprecate them and add KDFs to replace them.
>>> Deprecate them, leave them alone and hope they go away painlessly at
>> some point.
>> 
>> I really see no point in adding something that we at the same time
>> would like to remove. Just deprecate it.
>> 
>> 
>> Kurt
> 
> -- 
> Richard by mobile



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 these two
>functions yet.
>> Deprecate them and add KDFs to replace them.
>> Deprecate them, leave them alone and hope they go away painlessly at
>some point.
>
>I really see no point in adding something that we at the same time
>would like to remove. Just deprecate it.
>
>
>Kurt

-- 
Richard by mobile


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 some 
> point.

I really see no point in adding something that we at the same time
would like to remove. Just deprecate it.


Kurt



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 them.
>>>  3. Deprecate them, leave them alone and hope they go away
>>> painlessly at
>>> some point.
>>
>> 2 is really just and extension of 3 - either way we deprecate them.
>> In 2
>> we additionally provide a replacement.
>>
>> I definitely think they *should* be deprecated.
>>
>> Any replacement would necessarily go in the "legacy" provider I
>> think.
>> If a replacement is not difficult I would favour that. But I could
>> live
>> with (2).
> 
> Did you mean (3) here actually?
> 

Sorry - yes - that's what I meant!

I would prefer us to deprecate and add a replacement (option 2). But I
could live with just deprecating (option 3).

Matt


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 and hope they go away
> > painlessly at
> > some point.
> 
> 2 is really just and extension of 3 - either way we deprecate them.
> In 2
> we additionally provide a replacement.
> 
> I definitely think they *should* be deprecated.
> 
> Any replacement would necessarily go in the "legacy" provider I
> think.
> If a replacement is not difficult I would favour that. But I could
> live
> with (2).

Did you mean (3) here actually?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 just and extension of 3 - either way we deprecate them. In 2
we additionally provide a replacement.

I definitely think they *should* be deprecated.

Any replacement would necessarily go in the "legacy" provider I think.
If a replacement is not difficult I would favour that. But I could live
with (2).

Matt


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, they
> will no longer be reachable via EVP.  The confounding point is that
> they aren’t quite DES — close but not identical.  I would be
> surprised if they aren’t still in use for /etc/passwd files on old
> and/or embedded systems.
> 
> 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
> some point.

As deprecation is NOT a removal and the removal is at least 5 years in
future I think the third option is clearly OK. We could argue about any
other functionality that we deprecate the same way and we would not be
able to deprecate anything.

When we get in time to the point of removal of the functionality
deprecated in 3.0 we might even decide to selectively postpone the
removal of this particular thing although I do not think that would be
necessary. Use of these calls should be really abandoned anyway as the
old crypt() algorithm is totally weak anyway.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]




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 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.
> 
> Removing these calls will require an OMC vote as a breaking API change.  I’m 
> fine to call one if
> it seems justified.
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> On 17 Jan 2020, at 5:41 pm, Viktor Dukhovni  
> wrote:
>
> On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> 
> There are two functions (DES_crypt and DES_fcrypt) which implement the
> old crypt(3) password algorithm.  Once these are deprecated, they will
> no longer be reachable via EVP.  The confounding point is that they
> aren’t quite DES ― close but not identical.  I would be surprised if
> they aren’t still in use for /etc/passwd files on old and/or embedded
> systems.
> 
> Generally speaking, on Unix-like systems that use crypt(3) for
> /etc/passwd I'd expect to find a standaline crypt() implementation in
> libc, that is independent of OpenSSL.  That is, if your system still
> uses crypt() for passwords, you don't need OpenSSL to compute crypt
> hashes.
>
> That said, this is experience from general-purpose computers running
> Unix-like OSes, not embedded systems, where I have no idea whether
> crypt() is popular, and whether it is provided by a port of libcrypto
> to that platform.
> 
> 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 some point.
> 
> I would not expect to find many users of OpenSSL's crypt(), except
> internally within OpenSSL itself.
> 
> The apps/password.c applet calls these which is how I stumbled over
> the complication.  I’m fine refactoring this based on the solution
> chosen.  I’d also be okay with factoring out all the password
> derivation functions into KDFs if necessary.
>
> Thoughts?  Other alternatives?
> 
> I don't know enough about embedded systems to speak about what if
> anything we need to do for those with respect to crypt().
>
> --
>Viktor.
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


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.

Removing these calls will require an OMC vote as a breaking API change.  I’m 
fine to call one if it seems justified.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 17 Jan 2020, at 5:41 pm, Viktor Dukhovni  
> wrote:
> 
> On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote:
> 
>> There are two functions (DES_crypt and DES_fcrypt) which implement the
>> old crypt(3) password algorithm.  Once these are deprecated, they will
>> no longer be reachable via EVP.  The confounding point is that they
>> aren’t quite DES — close but not identical.  I would be surprised if
>> they aren’t still in use for /etc/passwd files on old and/or embedded
>> systems.
> 
> Generally speaking, on Unix-like systems that use crypt(3) for
> /etc/passwd I'd expect to find a standaline crypt() implementation in
> libc, that is independent of OpenSSL.  That is, if your system still
> uses crypt() for passwords, you don't need OpenSSL to compute crypt
> hashes.
> 
> That said, this is experience from general-purpose computers running
> Unix-like OSes, not embedded systems, where I have no idea whether
> crypt() is popular, and whether it is provided by a port of libcrypto
> to that platform.
> 
>> 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 some point.
> 
> I would not expect to find many users of OpenSSL's crypt(), except
> internally within OpenSSL itself.
> 
>> The apps/password.c applet calls these which is how I stumbled over
>> the complication.  I’m fine refactoring this based on the solution
>> chosen.  I’d also be okay with factoring out all the password
>> derivation functions into KDFs if necessary.
>> 
>> Thoughts?  Other alternatives?
> 
> I don't know enough about embedded systems to speak about what if
> anything we need to do for those with respect to crypt().
> 
> -- 
>Viktor.