Crypto, passwords

[Hal Murray]

devel at ntpsec.org said:
>> Should we fix the code that reads keys to allow text for other
>> types than MD5?

> I've had this on my mind for a while, but it seems like the kind of thing
> where we might want to float a draft RFC before implementing.

> We need to be careful here because the existing implementation has backed us
> into an odd corner; the only way to distinguish among hash types is by the
> length of the hash. 

That's not the question I was trying to ask.

I was inquiring about reading keys from the keys file.  You are talking about 
bits on the wire.

It's actually more complicated than length==5 for MD5.  The type (MD5) is 
also in the keys file.  I don't know what the code actually does.

I believe the plan is to switch to a type+length+body format for packet 
extensions.  Backward compatibility requires adding dummy extensions if 
required to avoid the magic lengths the current code understands or maybe 
just make the total length more than the longest of the grandfathered 
lengths.  (No need for NTPv5, at least for this reason.)


I just looked at the code to answer my question.

                 * Finally, get key and insert it. If it is longer than 20
                 * characters, it is a binary string encoded in hex;
                 * otherwise, it is a text string of printable ASCII
                 * characters.

If ntpq has code to read passwords from the keyboard, we should copy that 
hack.

I was slightly confused by ntpkeygen making text for MD5 and hex for SHA1.



-- 
These are my opinions.  I hate spam.