pure Perl SHA-256 crypt()

autocesco has asked for the wisdom of the Perl Monks concerning the following question:

Salutations, o pious Monks,
I am looking for some words of wisdom.

I have a DB where Linux machines are authenticating multiple services over tables filled with SHA-256 crypt() hashes. These are the ones looking like "$5$saltsaltsaltsalt$" followed by the actual hash, as introduced in Linux with glibc 2.7. The reference documentation is the man 3 crypt page of a recent Linux distribution.

Now, upcoming NetBSD machines would need to draw in the same tables in order to authenticate, but the system crypt() here is not providing support for SHA-256 "$5$..." hashes.

Is it found, in the abyss of your wisdom, a clue about where can I look for a pure Perl implementation of such a crypt() function ?

Blessed are You, who scribe the varieties of matters with only one Language.

Comment on pure Perl SHA-256 crypt()

Replies are listed 'Best First'.
Re: pure Perl SHA-256 crypt() by moritz (Cardinal) on Sep 05, 2011 at 14:04 UTC
My linux must be too old (Debian stable) because I don't see a reference implementation in there, but here is one. This document also comes with a textual description of the algorithm, which might be better suited for a perl re-implementation (in case nobody knows of an existing implementation). But wouldn't it be much easier to use the C reference implementation? Why does it need to be perl? You just need a C compiler on one of the machines, and then you can copy the compiled binary to all the other machines. Perl 6 - second systems done right	[reply]
Re^2: pure Perl SHA-256 crypt() by autocesco (Initiate) on Sep 05, 2011 at 15:41 UTC
Thanks for the referenced documentation, moritz. The algorithm described before the source is not clearly just a SHA-256 digest. I was able to compile the source on *bsd , just providing auxiliary implementations for mempcpy() and stpncpy() GNU functions. I preferred a pure Perl implementation just because my authentication scripts are all Perl, and for future portability. Before trying, I believed that the sha256-crypt from glibc2.7 was too much GNU to port it with ease. Unfortunately so, I'm not going to write sha256-crypt for Perl, but I will follow moritz' suggestion and plug this external C binary : /	[reply]
Re^2: pure Perl SHA-256 crypt() by autocesco (Initiate) on Sep 08, 2011 at 12:18 UTC
I finally found one in Crypt::Passwd::XS::unix_sha256_crypt() , it is not pure Perl but portable enough for my needs. It is based on the reference C implementation linked by moritz	[reply]
Re: pure Perl SHA-256 crypt() by Anonymous Monk on Sep 05, 2011 at 14:15 UTC
blah blah blah I not check cpan Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512	[reply]
Re^2: pure Perl SHA-256 crypt() by moritz (Cardinal) on Sep 05, 2011 at 14:18 UTC
I'm not too deep into cryptography, so please pardon my ignorance, but... What exactly is the relation between the SHA-256 digest and the SHA-256 mode of crypt()? Is the latter just a bit of pre processing and post processing around the former? Perl 6 - second systems done right	[reply]
Re^3: pure Perl SHA-256 crypt() by Anonymous Monk on Sep 05, 2011 at 14:27 UTC
blah blah blah, I not understand question :/	[reply]
Re^4: pure Perl SHA-256 crypt() by moritz (Cardinal) on Sep 05, 2011 at 14:30 UTC
Re^5: pure Perl SHA-256 crypt() by zentara (Cardinal) on Sep 05, 2011 at 14:45 UTC
Re^5: pure Perl SHA-256 crypt() by Perlbotics (Archbishop) on Sep 05, 2011 at 15:30 UTC
Re: pure Perl SHA-256 crypt() by locked_user sundialsvc4 (Abbot) on Sep 06, 2011 at 17:46 UTC
I wonder if this is an appropriate time for your company to Meditate on whether now might be a very good time to replace that authentication mechanism with, say, LDAP? There are many good reasons to consider such a thing, especially when multiple hardware platforms are beginning to enter the mix. It is at such a juncture that systems begin to become un-manageable, i.e. strictly from a corporate infrastructure-management point of view. You really do want to be able to control everything from one centralized, consistent administrative interface. This is usually not how systems begin, but when the bullet is finally bitten and the legacy systems are changed, the company often breathes an immense sigh of relief. I personally suggest that the idea should be submitted for very serious consideration. Perhaps, to quote Ensign Chekov, “Now would be a very good time, Scotty...”