EVP Message Digest requests
Support for SHA-224 SHA-256-SHA-384 and SHA-512 hashes has been added to rlm_pap. The correct digest algo is determined by the length of the value of SHA2-Password. 28 bytes - SHA-224 32 bytes - SHA-256 48 bytes - SHA-384 64 bytes - SHA-512 Password-With-Header prefixes {sha2},{sha256},{sha512} will all result in the Password-With-Header value being copied to a SHA2-Password attribute. {sha256},{sha512} match the password headers used by the slapd-sha2 module developed for OpenLDAP. Don't think many of the other hashes in OpenSSL's EVP_MD API are either widely used or appropriate for hashing passwords. But if someone knows differently then let me know. The equivalent xlats have also been added for SHA-256 and SHA-512, I don't think SHA-224 or SHA-384 are widely used enough to justify adding them, but it's only a two line patch if someone thinks differently. Does anyone have a burning need for any of the other hashes supported by EVP_MD? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
Support for SHA-224 SHA-256-SHA-384 and SHA-512 hashes has been added to rlm_pap. The correct digest algo is determined by the length of the value of SHA2-Password.
28 bytes - SHA-224 32 bytes - SHA-256 48 bytes - SHA-384 64 bytes - SHA-512
Wow, good news indeed! So, all those different lengths are so to speak "multiplexed" into one single "SHA2-Password" attribute? Also, what is the encoding? base64? A kinda logical next step would be to allow salted SHA2-x. The multiplexing wouldn't work there though due to unpredictable salt length... Stefan
Password-With-Header prefixes {sha2},{sha256},{sha512} will all result in the Password-With-Header value being copied to a SHA2-Password attribute. {sha256},{sha512} match the password headers used by the slapd-sha2 module developed for OpenLDAP.
Don't think many of the other hashes in OpenSSL's EVP_MD API are either widely used or appropriate for hashing passwords. But if someone knows differently then let me know.
The equivalent xlats have also been added for SHA-256 and SHA-512, I don't think SHA-224 or SHA-384 are widely used enough to justify adding them, but it's only a two line patch if someone thinks differently.
Does anyone have a burning need for any of the other hashes supported by EVP_MD?
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org <mailto:a.cudbardb@freeradius.org>> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 6 Feb 2014, at 19:46, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
Support for SHA-224 SHA-256-SHA-384 and SHA-512 hashes has been added to rlm_pap. The correct digest algo is determined by the length of the value of SHA2-Password.
28 bytes - SHA-224 32 bytes - SHA-256 48 bytes - SHA-384 64 bytes - SHA-512
Wow, good news indeed!
So, all those different lengths are so to speak "multiplexed" into one single "SHA2-Password" attribute? Also, what is the encoding? base64?
Binary, hex, or base64, it uses the same normifying logic as the other hashes. So I guess there's the extremely unlikely possibility a SHA512 digest which consisted entirely of hexits could be decoded as a SHA256 password, but that's why there's an option to turn normification off and do the conversion manually with the base64 xlat. Also, the odds of every single char of the output digest being between 48-57 65-70 97-102, hmm (26/256)^64 = 2.697345e-64 i.e. very unlikely.
A kinda logical next step would be to allow salted SHA2-x. The multiplexing wouldn't work there though due to unpredictable salt length...
I'd actually rather add a generic Salt attribute, and get rid of all the salted variants of functions. I think it can be done in a way that's backwards compatible. It just doesn't make sense having two versions of the code doing pretty much the same thing. In that case we could just reuse the 'multiplexed' attribute, but strip off salt based on the header. Where the password is stored in a database without a header, a header could be added as a hint using unlang, or people can do the decode and splitting manually, or store the salt in another column. Else were going to have to add four more attributes just to represent the salted versions. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Stefan Winter