| Re: [chrony-dev] Support for another crypto hash? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Fri, 4 Nov 2011, Miroslav Lichvar wrote:
On Thu, Nov 03, 2011 at 03:19:03PM +0000, Ed W wrote:
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)
I couldn't find a specification for the extended format.
Currently the password is a string of non-whitespace chars (as read by
sscanf()), so braces would be read as part of the password. Perhaps it
would be easier to always read it as hex or base64 if a hash name was
specified, i.e. use ASCII passwords only for the old format to stay
compatible?
- This storage format is not space efficient
How many keys do you typically have in chrony.keys?
- 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)
I'm not sure I understand how this works. The same hash function is
used multiple times on the same data?
Both the old des based hash and the new MD5 based hashes do a huge amount of
rerunning a similar hash function over the data, with mixing of the data
between the hashes to try to prevent condensation of the string of hashes (
Ie, Hash(Hash(hash(hash(....(hash(data))....)))) almost certainly cycles into
t fixed point eventually. The multiple hashes are there solely to slow down
the hash function, so that 100million per second. is brought down to 10 per
second or so. By the way, that 100million persecond is not for the password
hashes, but for simple hashes like sha or md whose whole design principle was
to be cryptographically secure AND be as fast as possible. Password hashes you
want to be very slow. )
If you look at /etc/shadow, the modern hashes there start with something like
$2a$08$kOm0. A $ sign is not in the list of 64 characters (one
for every 6 bits)(a-zA-Z0-9./) used to encode the hash output. (that is four printable characters to encode 24 bits, while hexedit uses 6 to encode 24 bits)
That intial $ tells the
crypt function that that password is not an old style DES based hashes, but is
a newer one. The next 2a tells it which one (blowfish based one) and then the
next numbers (08) tells it that one is to use 2^8 iterations.
The hashes are also augmented by a salt ( a publicly known--
published as part of the password-- random number to prevent precompiled
dictionary attacks). I am not at all sure that this is all necessary for
chrony. On the other hand, the software (crypt) is there on all linux/bsd/...
machines to generate and recognize all of the variants. The question is how
critical is it that that hash used in chrony not be broken in say 10 sec (or
10 years?) Passwords have to be safe for months. Do the chrony hashes need to
be? The password hash comes at a cost-- slowness. And a program whose purpose
is fast efficient time transfer, slowness is not an advantage.
See man crypt
- 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...
If the keyfile was encrypted, the key to that file would still have to
be somewhere in cleartext, or how would be chronyd started?
No. That is precisely what the originators of Unix realised, that it is was
just as easy, and much safer, to store the hash of the key. Then when the user
typed in their password, the hash of that password could be compared with the
hash of the true key to decide if it was correct. No need to store the
cleartext password ever.
Of course if you want chrony to start up automatically, without user input,
you would have to store that password in the clear somewhere.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
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.