On 10 Jan 2015, at 04:40, Robert Graham <robert_graham@uhaul.com> wrote:
Oh nevermind then, Im running 3.0.6....
Yeah FreeRADIUS 3.0.6 will work with SHA-224 SHA-256 SHA-384 and SHA-512. It can produce hashes for SHA-256 and SHA-512 (using xlat expansions). For SHA2 must be built with OpenSSL whereas, we fallback to our own internal implementations of SHA1 and MD5 if OpenSSL isn't available. Looking through the code it doesn't support SSHA2, because the SHA-2 digest is chosen automatically based on the digest length, and adding a random length salt messes that up. Think the idea was to add a Salt-Length attribute, to avoid adding the 8 additional attributes required for the salt and unsalted version of each of the SHA2 hashes, but after seeing how many issues relatively simple changes like removing Auth-Type from LDAP caused, I think it'd probably be best to stick with the current scheme and add: sha224-password ssha224-password sha256-password ssh256-password sha384-password ssha384-password sha512-password ssha512-password We can still keep sha2-password, and still do the autodetection there, but we can't support a salted variant. I'm generally against backporting features to a version which has been 'feature frozen'. This case is no exception. If we're going to make policies regarding merging features we should stick to them. Backporting the SHA2 changes is not risk free, as there's some changes to how we initialise libssl to get access to all the EVP hashing functions which were not used before SHA2 support was added. Sounds like this discussion is irrelevant as OP doesn't require SHA2 anyway, but I would be curious if they require SSHA2 support, and what the FIPS guidelines say on salting the hashes, and whether that's vital. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2