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 <openssl-users at dukhovni.org> 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/