NTP(4.2.8p18) SHA2 not working

[Samiya Khanum via questions Mailing List]

Hi,

I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Thanks & Regards,
Samiya khanum
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Dave Hart]

Post by Samiya Khanum via questions Mailing List
Hi,

Hello, Samiya.

I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.

Post by Samiya Khanum via questions Mailing List
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Was SHA2 working for you with an earlier version? If not, try SHA1.

I'm working on a change to enable ntpd to support stronger digest
algorithms that produce more than 160 bits. It will only use the first 160
bits of the digest, but it will still be a stronger signature using the
more modern digests. Using that test version, I don't see SHA2 supported
by OpenSSL 3.x, but I see SHA256, SHA384, and SHA512, which I'm guessing
are SHA2 with different digest lengths, as there are also SHA3-224,
SHA3-256, SHA3-384, and SHA3-512 available.

For a complete list of digests algorithms supported by your ntpd, try:

ntpq -c "help keytype"
Cheers,
Dave Hart

[Samiya Khanum via questions Mailing List]

Hi Dave,

Thank you for your response.

Yes, in the previous version "4.2.8p17", SHA2 is working fine.

I have built NTP with OpenSSL library version 3.1.5.
The supported algorithms in both NTP versions are the same.
*# ntpq -c "help keytype"*
*function: set key type to use for authenticated requests, one of:*
* AES128CMAC, MD5, RIPEMD160, SHA1, SHAKE128*

I am wondering how SHA2 is working in the previous version and not in the
latest version(4.2.8p18). Could you please elaborate more on this?

Thanks & Regards,
Samiya khanum

Post by Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi,

Hello, Samiya.
I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.

Post by Samiya Khanum via questions Mailing List
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Was SHA2 working for you with an earlier version? If not, try SHA1.
I'm working on a change to enable ntpd to support stronger digest
algorithms that produce more than 160 bits. It will only use the first 160
bits of the digest, but it will still be a stronger signature using the
more modern digests. Using that test version, I don't see SHA2 supported
by OpenSSL 3.x, but I see SHA256, SHA384, and SHA512, which I'm guessing
are SHA2 with different digest lengths, as there are also SHA3-224,
SHA3-256, SHA3-384, and SHA3-512 available.
ntpq -c "help keytype"
Cheers,
Dave Hart

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Samiya Khanum via questions Mailing List]

Hi Dave,

Could you please respond to the email.

Thanks & Regards,
Samiya khanum

Post by Samiya Khanum via questions Mailing List
Hi Dave,
Thank you for your response.
Yes, in the previous version "4.2.8p17", SHA2 is working fine.
I have built NTP with OpenSSL library version 3.1.5.
The supported algorithms in both NTP versions are the same.
*# ntpq -c "help keytype"*
*function: set key type to use for authenticated requests, one of:*
* AES128CMAC, MD5, RIPEMD160, SHA1, SHAKE128*
I am wondering how SHA2 is working in the previous version and not in the
latest version(4.2.8p18). Could you please elaborate more on this?
Thanks & Regards,
Samiya khanum

Post by Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi,

Hello, Samiya.
I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.

Post by Samiya Khanum via questions Mailing List
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Was SHA2 working for you with an earlier version? If not, try SHA1.
I'm working on a change to enable ntpd to support stronger digest
algorithms that produce more than 160 bits. It will only use the first 160
bits of the digest, but it will still be a stronger signature using the
more modern digests. Using that test version, I don't see SHA2 supported
by OpenSSL 3.x, but I see SHA256, SHA384, and SHA512, which I'm guessing
are SHA2 with different digest lengths, as there are also SHA3-224,
SHA3-256, SHA3-384, and SHA3-512 available.
ntpq -c "help keytype"
Cheers,
Dave Hart

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Dave Hart]

Thanks for the reminder to respond, I managed to miss the your first
response due to a fast-filling inbox, please accept my apologies.

Thank you also for letting me know this is a regression in 4.2.8p18
compared to 4.2.8p17, it helps prioritize the problem. I have already been
working on a fix, in fact, as it affects many algorithms, not just SHA2.
The problem is with some changes I made in this code to rationalize the
return value of a function, which was returning the total MAC size on
success, and 4 on failure, which is the size in bytes of the key number
without the actual digest signature which would be there on success. I
changed it to return zero in the failure case, which is a more common
expected pattern, but failed to change all the places that touch it.

I should have a patch available soon. Rather than a laser-focused patch,
I've been also working to update the unit tests around symmetric keys and
improve the "help keytype" output to reflect which algorithms will actually
work, after observing the behavior with OpenSSL 3 with and without FIPS
mode enabled, which disables some older digest algorithms but didn't
prevent them from appearing in "help keytype" output.

Please file a bug report at https://bugs.ntp.org/ to track the issue. I've
been tracking it under the re-opening of https://bugs.ntp.org/3940 but it
would be best to have a new report noting it's a regression which will also
enable you to be notified when I have a fix ready to test.

Cheers,
Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi Dave,
Thank you for your response.
Yes, in the previous version "4.2.8p17", SHA2 is working fine.
I have built NTP with OpenSSL library version 3.1.5.
The supported algorithms in both NTP versions are the same.
*# ntpq -c "help keytype"*
*function: set key type to use for authenticated requests, one of:*
* AES128CMAC, MD5, RIPEMD160, SHA1, SHAKE128*
I am wondering how SHA2 is working in the previous version and not in the
latest version(4.2.8p18). Could you please elaborate more on this?
Thanks & Regards,
Samiya khanum

Post by Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi,

Hello, Samiya.
I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.

Post by Samiya Khanum via questions Mailing List
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Was SHA2 working for you with an earlier version? If not, try SHA1.
I'm working on a change to enable ntpd to support stronger digest
algorithms that produce more than 160 bits. It will only use the first 160
bits of the digest, but it will still be a stronger signature using the
more modern digests. Using that test version, I don't see SHA2 supported
by OpenSSL 3.x, but I see SHA256, SHA384, and SHA512, which I'm guessing
are SHA2 with different digest lengths, as there are also SHA3-224,
SHA3-256, SHA3-384, and SHA3-512 available.
ntpq -c "help keytype"
Cheers,
Dave Hart

This electronic communication and the information and any files
transmitted with it, or attached to it, are confidential and are intended
solely for the use of the individual or entity to whom it is addressed and
may contain information that is confidential, legally privileged, protected
by privacy laws, or otherwise restricted from disclosure to anyone else. If
you are not the intended recipient or the person responsible for delivering
the e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

[Samiya Khanum via questions Mailing List]

Hi Dave,

I appreciate you taking the time to respond and thank you for providing the
information.

I have filed the bug below, please let me know if any fields need to be set
in the bug.
https://bugs.ntp.org/show_bug.cgi?id=3954

Thanks & Regards,
Samiya khanum

Post by Dave Hart
Thanks for the reminder to respond, I managed to miss the your first
response due to a fast-filling inbox, please accept my apologies.
Thank you also for letting me know this is a regression in 4.2.8p18
compared to 4.2.8p17, it helps prioritize the problem. I have already been
working on a fix, in fact, as it affects many algorithms, not just SHA2.
The problem is with some changes I made in this code to rationalize the
return value of a function, which was returning the total MAC size on
success, and 4 on failure, which is the size in bytes of the key number
without the actual digest signature which would be there on success. I
changed it to return zero in the failure case, which is a more common
expected pattern, but failed to change all the places that touch it.
I should have a patch available soon. Rather than a laser-focused patch,
I've been also working to update the unit tests around symmetric keys and
improve the "help keytype" output to reflect which algorithms will actually
work, after observing the behavior with OpenSSL 3 with and without FIPS
mode enabled, which disables some older digest algorithms but didn't
prevent them from appearing in "help keytype" output.
Please file a bug report at https://bugs.ntp.org/ to track the issue.
I've been tracking it under the re-opening of https://bugs.ntp.org/3940
but it would be best to have a new report noting it's a regression which
will also enable you to be notified when I have a fix ready to test.
Cheers,
Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi Dave,
Thank you for your response.
Yes, in the previous version "4.2.8p17", SHA2 is working fine.
I have built NTP with OpenSSL library version 3.1.5.
The supported algorithms in both NTP versions are the same.
*# ntpq -c "help keytype"*
*function: set key type to use for authenticated requests, one of:*
* AES128CMAC, MD5, RIPEMD160, SHA1, SHAKE128*
I am wondering how SHA2 is working in the previous version and not in the
latest version(4.2.8p18). Could you please elaborate more on this?
Thanks & Regards,
Samiya khanum

Post by Dave Hart

Post by Samiya Khanum via questions Mailing List
Hi,

Hello, Samiya.
I have upgraded NTP to 4.2.8p18, and the OpenSSL to 3.1.5.

Post by Samiya Khanum via questions Mailing List
NTP time sync with SHA2 key is not working, can you please let us know
whether SHA2 is supported on this version or not.

Was SHA2 working for you with an earlier version? If not, try SHA1.
I'm working on a change to enable ntpd to support stronger digest
algorithms that produce more than 160 bits. It will only use the first 160
bits of the digest, but it will still be a stronger signature using the
more modern digests. Using that test version, I don't see SHA2 supported
by OpenSSL 3.x, but I see SHA256, SHA384, and SHA512, which I'm guessing
are SHA2 with different digest lengths, as there are also SHA3-224,
SHA3-256, SHA3-384, and SHA3-512 available.
ntpq -c "help keytype"
Cheers,
Dave Hart

This electronic communication and the information and any files
transmitted with it, or attached to it, are confidential and are intended
solely for the use of the individual or entity to whom it is addressed and
may contain information that is confidential, legally privileged, protected
by privacy laws, or otherwise restricted from disclosure to anyone else. If
you are not the intended recipient or the person responsible for delivering
the e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.