# SHA256 authentication

**URL:** <https://community.ntppool.org/t/sha256-authentication/3382>\
**Category:** Uncategorized\
**Created:** [May 19, 2024, 6:11pm UTC](https://community.ntppool.org/t/sha256-authentication/3382 "2024-05-19T18:11:27Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![0xpatrik](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/0xpatrik/32/1358_2.png) [@0xpatrik](https://community.ntppool.org/u/0xpatrik)\
**Post date:** [May 19, 2024, 6:11pm UTC](https://community.ntppool.org/t/sha256-authentication/3382/1 "2024-05-19T18:11:28Z")

</div>

Hi all,

I am trying to develop a custom NTP server using Python. I have the basic functionality working well. When I started to add authentication, I ran into an issue that RFC5905 defines “message digest” as 128-bit value. This makes sense for MD5 hashes, however, I have seen multiple options to configure clients with SHA1, SHA256, … hashes that are clearly longer than 128-bits.

Can somebody explain me how is this supposed to work? When trying to look at chrony or ntpd implementations, I can’t really find any SHA-related code.

Any relevant source would be great.

Thanks!

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/mnordhoff/32/1470_2.png) [@mnordhoff](https://community.ntppool.org/u/mnordhoff)\
**Post date:** [May 19, 2024, 8:40pm UTC](https://community.ntppool.org/t/sha256-authentication/3382/2 "2024-05-19T20:40:08Z")

</div>

I want to say they’re truncated or [you can use a longer one if you want to](https://datatracker.ietf.org/doc/html/rfc7822#page-5) but I’m not sure.

No one asked, but I would personally endorse implementing [AES-CMAC](https://datatracker.ietf.org/doc/html/rfc8573) instead, which can produce 128-bit MACs anyway. 🙂

(I don’t like the hash-based “MACs” because they don’t use a [proper construction](https://en.wikipedia.org/wiki/HMAC#Design_principles) like [HMAC](https://en.wikipedia.org/wiki/HMAC). Though this is less of a problem with SHA-3, which Chrony supports.)

---

<div class="post-metadata">

**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\
**Post date:** [May 20, 2024, 7:41am UTC](https://community.ntppool.org/t/sha256-authentication/3382/3 "2024-05-20T07:41:12Z")

</div>

In NTPv4 messages the digests are truncated to 160 bits to follow the recommendations of RFC 7822 to avoid ambiguities in parsing of extension fields. The last extension field should have at least 28 bytes. In NTPv3 the digests can be as long as you like, there were no extension fields yet. IIRC this is not officially specified anywhere, it’s just what the common implementations do.

---

<div class="post-metadata">

**Author:** ![0xpatrik](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/0xpatrik/32/1358_2.png) [@0xpatrik](https://community.ntppool.org/u/0xpatrik)\
**Post date:** [May 20, 2024, 8:14am UTC](https://community.ntppool.org/t/sha256-authentication/3382/4 "2024-05-20T08:14:25Z")

</div>

Thanks for the reply!

From the RFC 5905 - the digest is 128 bits and keyid is 32 bits. When you say that digest is truncated to 160 bits, does it mean that both those fields are used to carry the digest information? Or simply that digest field should carry 160 bits alone?

Currently, my last piece of data (for NTP4) is “transmit timestamp”. If I understand correctly, I should then:

- Add zero padding for extension fields (28 bytes)
- Get digest from sha256(key+data\_without\_extension\_fields)
- Get the packet data as “data\_without\_extension\_fields+padding+keyid+digest”

Is that about right?

---

<div class="post-metadata">

**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\
**Post date:** [May 20, 2024, 10:48am UTC](https://community.ntppool.org/t/sha256-authentication/3382/5 "2024-05-20T10:48:49Z")

</div>

It’s 32 bits for the key ID and first 160 bits of the SHA256 sum. Together that is 24 bytes, which is the maximum length smaller than 28 bytes and divisible by 4.

The SHA256 sum should be calculated over all data preceding the MAC field, including any extension fields.

---

<div class="post-metadata">

**Author:** ![0xpatrik](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/0xpatrik/32/1358_2.png) [@0xpatrik](https://community.ntppool.org/u/0xpatrik)\
**Post date:** [May 20, 2024, 3:40pm UTC](https://community.ntppool.org/t/sha256-authentication/3382/6 "2024-05-20T15:40:39Z")

</div>

Does it mean that I am not required to add any extension field and just append MAC after “transmit timestamp” with the total length of 24 bytes?

---

<div class="post-metadata">

**Author:** ![mlichvar](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@mlichvar](https://community.ntppool.org/u/mlichvar)\
**Post date:** [May 20, 2024, 4:04pm UTC](https://community.ntppool.org/t/sha256-authentication/3382/7 "2024-05-20T16:04:07Z")

</div>

Yes, extension fields are optional.
