r2 - 2017-12-15 - 16:11:23 - JuergenPerlingerYou are here: NTP >  Dev Web > DevelopmentIssues > NtpAuthKeyStringFormat
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

NTP's Authentication Key String Format

The ntp.keys file contains a list of symmetric keys, in the form:



  • NN - a number, between 1 and 65535.
  • AAA - the digest algorithm. md5 has always been available, and others are available if ntpd was compiled with OpenSSL support.
  • KKK - the key value.

The Key Value

The key value might need to be quoted.

We already allow a hex string:

(useful example)

What about quoting?

Should we allow a means to specify non-graphic characters in a string?


The following transformations would be supported:

  • hex - covert the characters 0-9A-Fa-f to their hexadecimal equivalent
  • str - treat whatever follows as a string, providing '\' escape sequence expansion (ANSI escapes, \ooo and \xHH) to embed special characters.
  • md5 - pass the key through the md5 digest
  • DIGEST - any other digest that is available to the process. When the OpenSSL libraries are provided, this list may include DSA, DSA-SHA, MD4, MD5, MDC3, RIPEMD160, SHA, SHA1, SHA224, SHA256, SHA384, or SHA512.(Note that AES128CMAC is not an option here, as this would create a cyclic dependency.)

Some hash algorithms care very much about the length of a key.

While 'hex' and 'str' encoding can be oviously used to encode the same key in different ways, both have their use. If it is truly binary material, then the 'hex' encoding is more convenient. The 'str' encoding is easier for the occasional unprintable character or embedded blank.

Current idea: allow a list of transformations, applied in left-to-right order:

20 aes128cmac [hex,md5]beef
25 aes128cmac [sha256,16]hello

20 aes128cmac [hex,md5]beef would assign keyID 20 to be an aes128cmac key produced by taking the 4 characters beef and running them through a hex converter, then taking the result and sending it through the md5 processor, resulting in a 16 byte key.

25 aes128cmac [sha256,16]hello would assign keyID 25 to be an aes128cmac key produced by taking the 5 characters hello and sending them through the sha256 digest, and then taking the first 16 bytes of that result.


Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback