Re: crypt(3)

[Dr Paul Dale]

Thanks for the feedback everyone.


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

Re: crypt(3)

[Salz, Rich]

  *   I meant “what default makes the most sense for the passwd command line 
application?”
  *   It was crypt which is deprecated.  Should it be BSD’s MD5?  One of the 
SHA2 based algorithms?  Or should it produce an error if no algorithm is 
selected?

If you change the default, then the program will work differently depending on 
whether or not no-deprecated is configured.  This means that developers who 
want to write portable scripts will find it difficult to do so. People who have 
existing scripts and get a system upgrade could find things broken in a really 
strange way. This is *not* the same as when the default digest mechanism 
changed, because it was still available.

Re: crypt(3)

[Roumen Petrov]

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.

[SNIP]

Thoughts?  Other alternatives?


Linux and BSD crypt(3) manual pages refer to crypt library.  Also 
crypt(3) is not only for DES. It has more features. Why to use OpenSSL 
functions then?


Also OpenSSL build now does not remove deprecated function. So package 
manages could decide API level compatibility and in addition to remove 
or not deprecated functions.


Regards,
Roumen Petrov

Re: crypt(3)

[Viktor Dukhovni]

On Sun, Jan 19, 2020 at 12:26:06PM +0100, Kurt Roeckx wrote:

> The only thing that we support currently that makes sense as a
> default is -5 (sha256) and -6 (sha512). I suggest you go with -6.

I concur, FWIW this is the default password hash for my FreeBSD 12
server, so it is not a Linux-only construct.

-- 
Viktor.

Re: crypt(3)

[Kurt Roeckx]

On Sun, Jan 19, 2020 at 11:45:07AM +1000, Dr Paul Dale wrote:
> I meant “what default makes the most sense for the passwd command line 
> application?”
> It was crypt which is deprecated.  Should it be BSD’s MD5?  One of the SHA2 
> based algorithms?  Or should it produce an error if no algorithm is selected?

I would actually like to go for something modern in that case,
like argon2 (argon2id). We have an open issue
(https://github.com/openssl/openssl/issues/4091) and pull request
(https://github.com/openssl/openssl/pull/9444) for argon2. PHP
seems to have made a format for it that's compatible with crypt():
https://wiki.php.net/rfc/argon2_password_hash_enhancements
But the argon2 RFC hasn't been published yet, so I think that
might need to wait.

The only thing that we support currently that makes sense as a
default is -5 (sha256) and -6 (sha512). I suggest you go with -6.


Kurt

Re: crypt(3)

[Dr Paul Dale]

I meant “what default makes the most sense for the passwd command line 
application?”
It was crypt which is deprecated.  Should it be BSD’s MD5?  One of the SHA2 
based algorithms?  Or should it produce an error if no algorithm is selected?


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




> On 19 Jan 2020, at 12:28 am, Kurt Roeckx  wrote:
> 
> On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote:
>> Could the people who work with distros confirm this default choice or 
>> suggest what they use please?
> 
> I'm not sure what you're asking, but crypt() has moved on from
> using DES like 20 years ago, see crypt(5).
> 
> 
> Kurt
> 

Re: crypt(3)

[Kurt Roeckx]

On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote:
> Could the people who work with distros confirm this default choice or suggest 
> what they use please?

I'm not sure what you're asking, but crypt() has moved on from
using DES like 20 years ago, see crypt(5).


Kurt

Re: crypt(3)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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.

Re: crypt(3)

[Viktor Dukhovni]

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.

Re: crypt(3)

[Dmitry Belyavsky]

Dear Paul,

The KDF variant seems the best one.

On Fri, Jan 17, 2020 at 9:33 AM 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:
>
>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.
>
>
> 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?
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>

-- 
SY, Dmitry Belyavsky

crypt(3)

[Dr Paul Dale]

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.

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?


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