On Tue, Apr 30, 2019 at 04:08:47PM +0000, greg.d...@microchip.com wrote: > However, in operation things get weird. Md5 and sha1 are fine. Ripemd160 is > successful but I think that is just lucky because it has a 160bit digest that > ends up looking like a sha1 mac. However, I "think" because I don't have > support in openssl, sha224, 256, and 384 don't even try to send MAC frames, > just regular no auth. So they look like they work but they have no MAC. > Sha512 actually generates a 64 byte mac and stuffs all of it in the frame so > 68 bye HMAC (with key) but this gets parsed as an extension and fails. > > So what's up? Is this like somewhere in the middle of development? I > remember discussions about have an extension field to either negotiate or at > least identify digest algorithms but I don't think this is that.
Latest ntp-4.2.8 versions should truncate digests longer than 160 bits (192-bit MAC). What version were you testing? I'm not sure in which one exactly this was introduced. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
