Re: crypt(3)
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)
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)
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
Re: 3.0 release timeline proposal
This vote has started. I'll report back when we have an answer. Matt On 15/01/2020 09:12, Matt Caswell wrote: > Not much feedback, so I'm assuming everyone is ok with this proposal. > > I'm going to start a vote soon with this wording: > > "Update the release strategy to the text shown here: > https://github.com/openssl/web/pull/154/commits/959153c7e62865beae9f24364f1c971b149f477a; > > > > Matt > > > > > On 07/01/2020 16:54, Matt Caswell wrote: >> I converted this proposal into a PR to amend the release strategy. >> Please see: >> >> https://github.com/openssl/web/pull/154 >> >> Matt >> >> >> On 07/01/2020 11:13, Matt Caswell wrote: >>> Hi all >>> >>> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss >>> the outstanding tasks and effort required to get us to a final release. >>> >>> We've previously said this about that timeline: >>> >>> "We are now not expecting code completion to occur until the end of Q2 >>> 2020 with a final release in early Q4 2020." >>> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/) >>> >>> >>> With that in mind we came up with the following proposal for a release >>> timetable which we think is a challenging but achievable timeline: >>> >>> alpha1, 2020-03-31: Basic functionality plus basic FIPS module >>> alpha2, 2020-04-21: Complete external provider support (serialization, >>> support for new algs, support for providers which only include >>> operations in a class) >>> alpha3, 2020-05-21: Almost there (aiming to test the API completeness >>> before beta1 freezes it) >>> beta1, 2020-06-02: Code complete (API stable, feature freeze) >>> betaN: Other beta TBD >>> Final: 2020 early Q4 >>> >>> The idea here is to set some intermediate deadlines to focus attention >>> on the final remaining tasks, with a series of 3 alphas prior to the >>> first beta release where each alpha release comes approximately every 3 >>> weeks. We can have some flexibility to adjust this timetable if we think >>> it is necessary (such as by including an additional alpha release if >>> required). >>> >>> Please let me know your thoughts. This would probably need to go to an >>> OMC vote to get approved. >>> >>> Matt >>>
