Re: [chrony-dev] Support for another crypto hash?

[Ed W <lists@xxxxxxxxxxxxxx>]

On 02/11/2011 13:45, Miroslav Lichvar wrote:
> Would support for reading hex passwords be useful? Any suggestions on
> how to extend the format?

This isn't entirely thought through, but the unix crypt function defined
an "extensible" hash format, where the hash itself has a {type} prefix
to it.  I believe the point is that the { is not a normal character for
the hash storage format (base64? didn't check before writing this)

- This storage format is not space efficient

- The unix crypt functions are extended in recent glibc (and I posted a
uclibc patch recently) to include multiple iterated algorithms with a
view to making bruteforce more difficult. This is something worth
picking up on now that GPUs compute hashes at >100million per second...
Salt doesn't help you against that, so long, complex passwords are
necessary if you need resistance to bruteforcing password hashes...
(multiple iteration algorithms partially mitigate this)

- It would be nice if the password were not stored in the clear on the
ntp box.  However, with the exception of public key crypto, this is at
odds with secure password exchange on the wire...

- ECDSA public key signed exchanges...


Just a brain dump - sorry if it's not helpful...

Ed W

---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.