EVP Message Digest requests

Arran Cudbard-Bell a.cudbardb at freeradius.org
Thu Feb 6 23:56:53 CET 2014

On 6 Feb 2014, at 19:46, Stefan Winter <stefan.winter at 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 Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140206/845bf074/attachment-0001.pgp>

More information about the Freeradius-Devel mailing list