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-us...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/