Dr Paul Dale
paul.dale at oracle.com
Fri Jan 17 08:19:40 UTC 2020
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.
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
> 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
> 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().
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-project