openssl-users at dukhovni.org
Fri Jan 17 07:41:01 UTC 2020
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
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
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().
More information about the openssl-project