[RFC][PATCH][BZ 2100] blowfish support in libcrypt

[Björn Esser]

Am 01.06.2017 um 12:39 schrieb Dmitry V. Levin:
> On Thu, Jun 01, 2017 at 11:23:36AM +0200, Florian Weimer wrote:
>> On 05/31/2017 07:33 PM, Björn Esser wrote:
>>> +Solar Designer <solar at openwall.com>
>> I think we generally prefer patch submission from the original author or
>> copyright holder.

Before submitting this patch, I discussed it with the original author.  
The outcome about it was, that he tried to get this in some 10 years 
ago, but Ulrich Depper rejected it; he was fine with me submitting this 
again.

>> I'm quite sure the original author has no time for this, but you
>> definitely can contact him on this subject.
>>
>> Are the crypt_gensalt functions strongly related to Blowfish support?
> Not really.

They are not, but however most vendor patches to glibc (like SUSE, 
openwall, etc.) implement them.  Thus I added those crypt_gensalt 
functions for the sake of common usage along Blowfish support.

>
>> In any case, they need documentation,
> JFYI, crypt_blowfish comes with its own crypt(3) manual page documenting them.

As soon as there is an agreement about including this patch, I'll add 
the needed documentation to it.

>> and I'm not sure if the interfaces
>> are properly designed (haven't looked in detail, admittedly).
> They are properly designed, no doubts about it,
> unlike the infamous change of crypt(3) to return NULL for bad salt.
>
> As to this API extension, it's arguably even more important than having
> bcrypt support in libcrypt.
>
> The only drawback of adding crypt_gensalt et al functions without bcrypt
> is potential breakage of various configure scripts that decide whether
> to rely on bcrypt support in libcrypt or not based on the crypt_gensalt
> availability in libcrypt.
>
>> The other question is why we should add Blowfish support when the cipher
>> is pretty much on everyone's banned list.
> Is there any link between bcrypt support in libcrypt and Blowfish support
> in ssh/ssl/etc, besides a psychological one?

There is not link between them, but the cipher itself;  this 
implementation has been developed independently and was written with 
focus on password hashing instead of encryption of data streams.