From Newsgroup: comp.protocols.time.ntp

--0000000000002f132e063dbaac21
Content-Type: text/plain; charset="UTF-8"

Hi,

Request your comments.

I see the following error in the server, with sha256 keys: "receive: drop:
bad EF length"
The client and server are both 4.2.8.p18, same version. I see the client is sending 32 bytes MAC + 4 bytes key id.

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes ?
Why is the same p18 version in client and server not compatible ?

Any help/pointers much appreciated.

Thanks,
Murugesh

--0000000000002f132e063dbaac21
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Request your comments.</div><div><b= r></div><div>I see the following error in the server, with sha256 keys: &qu= ot;<span style=3D"color:rgb(0,0,0)">receive: drop: bad EF length&quot;</spa= n></div><div>The client and server are both 4.2.8.p18, same version. I see = the client is sending 32 bytes MAC=C2=A0+ 4 bytes key id. =C2=A0</div><div>= <br></div><div>Why is the server rejecting this mac ? should MAC be reduced=
to 20 bytes ?</div><div>Why is the same p18 version in client and server n=
ot compatible ?</div><div><br></div><div>Any help/pointers much appreciated= .</div><div><br></div><div>Thanks,</div><div>Murugesh</div><div><br></div><= div><br></div></div>

--0000000000002f132e063dbaac21--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--0000000000003567ce063dd97e99
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah <murugesh.pitchaiah@gmail.com> wrote:

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes ?


The MAC is too long and it should be trucated to 16 or 20 bytes long.

Why is the same p18 version in client and server not compatible ?


I do not know, my best guess is that the code missed a truncation.



--0000000000003567ce063dd97e99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 1, 2025, 03:21 murugesh pitc= haiah &lt;<a href=3D"mailto:murugesh.pitchaiah@gmail.com">murugesh.pitchaia= h@gmail.com</a>&gt; wrote:</div><div dir=3D"ltr" class=3D"gmail_attr"><br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_qu= ote"><div dir=3D"ltr"><div>Why is the server rejecting this mac ? should MA=
C be reduced to 20 bytes ?</div></div></div></div></blockquote></div></div>= <div dir=3D"auto"><br></div><div dir=3D"auto">The MAC is too long and it sh= ould be trucated to 16 or 20 bytes long.</div><div dir=3D"auto"><br></div><= div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir= =3D"ltr"><div>Why is the same p18 version in client and server not compatib=
le ?</div></div></div></div></blockquote></div></div><div dir=3D"auto"><br>= </div><div dir=3D"auto">I do not know, my best guess is that the code misse=
d a truncation.</div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quot= e_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"= gmail_quote">
</div></div>
</blockquote></div></div></div>

--0000000000003567ce063dd97e99--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000945198063ddaa429
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi James,

Thanks for your reply.

Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes along with keyid 4 bytes. But for that, the p18 server reported error "MAC
length error, received 24 not 36".

Assuming the p18 expects MAC without truncation I tried p18 for client. Now having p18 client and p18 server.

P18 client sending 32 plus 4. But p18 server reporting "bad EF length".

Thanks,
Murugesh

On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, <pessimus192@gmail.co=

wrote:

On Mon, Sep 1, 2025, 03:21 murugesh pitchaiah <
murugesh.pitchaiah@gmail.com> wrote:

Why is the server rejecting this mac ? should MAC be reduced to 20 bytes =

?

The MAC is too long and it should be trucated to 16 or 20 bytes long.

Why is the same p18 version in client and server not compatible ?

I do not know, my best guess is that the code missed a truncation.

--000000000000945198063ddaa429
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi James,<div dir=3D"auto"><br></div><div dir=3D"auto">Th= anks for your reply.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut= o">Initially I had 4.2.8.p12 client. It was sending MAC of size 20 bytes al= ong with keyid 4 bytes.=C2=A0 But for that, the p18 server reported error &= quot;MAC length error, received 24 not 36&quot;.</div><div dir=3D"auto"><br= ></div><div dir=3D"auto">Assuming the p18 expects MAC without truncation I = tried p18 for client. Now having p18 client and p18 server.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">P18 client sending 32 plus 4. But p18=
server reporting &quot;bad EF length&quot;.</div><div dir=3D"auto"><br></d= iv><div dir=3D"auto">Thanks,=C2=A0</div><div dir=3D"auto">Murugesh</div></d= iv><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Wed, 3 Sept, 2025, 5:32=E2=80=AFam James Browning, &l= t;<a href=3D"mailto:pessimus192@gmail.com">pessimus192@gmail.com</a>&gt; wr= ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div><div cl= ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 1, 20= 25, 03:21 murugesh pitchaiah &lt;<a href=3D"mailto:murugesh.pitchaiah@gmail= .com" target=3D"_blank" rel=3D"noreferrer">murugesh.pitchaiah@gmail.com</a>= &gt; wrote:</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir= =3D"ltr"><div>Why is the server rejecting this mac ? should MAC be reduced =
to 20 bytes ?</div></div></div></div></blockquote></div></div><div dir=3D"a= uto"><br></div><div dir=3D"auto">The MAC is too long and it should be truca= ted to 16 or 20 bytes long.</div><div dir=3D"auto"><br></div><div dir=3D"au= to"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l= tr"><div class=3D"gmail_quote"><div dir=3D"ltr"><div>Why is the same p18 ve= rsion in client and server not compatible ?</div></div></div></div></blockq= uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">I do not kno=
w, my best guess is that the code missed a truncation.</div><div dir=3D"aut= o"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= r"><div class=3D"gmail_quote">
</div></div>
</blockquote></div></div></div>
</blockquote></div>

--000000000000945198063ddaa429--

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jCuDCeO0MhdiqXrDrS7Kpdzd
Content-Type: multipart/mixed; boundary="------------Mic94HPB0lo00JkdJjD0Whev";
protected-headers="v1"
From: Martin Burnicki <martin.burnicki@meinberg.de>
To: murugesh pitchaiah <murugesh.pitchaiah@gmail.com>,
James Browning <pessimus192@gmail.com>
Cc: questions@lists.ntp.org
Message-ID: <00561447-2476-43f7-a9cc-7aa046e722e2@meinberg.de>
Subject: Re: SHA256 MAC with ntp 4.2.8.p18
References: <CAOu9RAcaCW7MEurs2FqmD6ZnUVMtNvjJMsZbKCDfviTg2fQDZw@mail.gmail.com>
<CAOu9RAepVz7b-fUXx=b0-poLVT3Rb_iWRLX8Mk23havg59kj4A@mail.gmail.com>
<CAHLN9Pdh2_6K+f-s4y7BHPLyxL6gR5fG4qz13rR_WaBX=wJ04g@mail.gmail.com>
<CAOu9RAccoL65TDSmMMQCmhbxWTUK21wCPOWtb-79s7goDrhLxg@mail.gmail.com> In-Reply-To: <CAOu9RAccoL65TDSmMMQCmhbxWTUK21wCPOWtb-79s7goDrhLxg@mail.gmail.com>

--------------Mic94HPB0lo00JkdJjD0Whev
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgTXVydWdlc2gsDQoNCkFzIGZhciBhcyBJIGtub3csIG50cGQgZnJvbSBudHAub3JnIGRv ZXNuJ3QgcmVhbGx5IHN1cHBvcnQgU0hBMjU2Lg0KDQpXb3VsZCBpdCBiZSBwb3NzaWJsZSB0 byB1c2UgQUVTMTI4Q01BQyBpbnN0ZWFkPyBUaGF0J3Mgc3VwcG9ydGVkIHdlbGwgYnkgDQpu dHBkLg0KDQoNClJlZ2FyZHMsDQoNCk1hcnRpbg0KDQoNCm11cnVnZXNoIHBpdGNoYWlhaCB3 cm90ZToNCj4gSGkgSmFtZXMsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQo+IA0K PiBJbml0aWFsbHkgSSBoYWQgNC4yLjgucDEyIGNsaWVudC4gSXQgd2FzIHNlbmRpbmcgTUFD IG9mIHNpemUgMjAgYnl0ZXMgDQo+IGFsb25nIHdpdGgga2V5aWQgNCBieXRlcy7CoCBCdXQg Zm9yIHRoYXQsIHRoZSBwMTggc2VydmVyIHJlcG9ydGVkIGVycm9yIA0KPiAiTUFDIGxlbmd0 aCBlcnJvciwgcmVjZWl2ZWQgMjQgbm90IDM2Ii4NCj4gDQo+IEFzc3VtaW5nIHRoZSBwMTgg ZXhwZWN0cyBNQUMgd2l0aG91dCB0cnVuY2F0aW9uIEkgdHJpZWQgcDE4IGZvciBjbGllbnQu IA0KPiBOb3cgaGF2aW5nIHAxOCBjbGllbnQgYW5kIHAxOCBzZXJ2ZXIuDQo+IA0KPiBQMTgg Y2xpZW50IHNlbmRpbmcgMzIgcGx1cyA0LiBCdXQgcDE4IHNlcnZlciByZXBvcnRpbmcgImJh ZCBFRiBsZW5ndGgiLg0KPiANCj4gVGhhbmtzLA0KPiBNdXJ1Z2VzaA0KPiANCj4gT24gV2Vk LCAzIFNlcHQsIDIwMjUsIDU6MzLigK9hbSBKYW1lcyBCcm93bmluZywgPHBlc3NpbXVzMTky QGdtYWlsLmNvbSANCj4gPG1haWx0bzpwZXNzaW11czE5MkBnbWFpbC5jb20+PiB3cm90ZToN Cj4gDQo+ICAgICBPbiBNb24sIFNlcCAxLCAyMDI1LCAwMzoyMSBtdXJ1Z2VzaCBwaXRjaGFp YWgNCj4gICAgIDxtdXJ1Z2VzaC5waXRjaGFpYWhAZ21haWwuY29tIDxtYWlsdG86bXVydWdl c2gucGl0Y2hhaWFoQGdtYWlsLmNvbT4+DQo+ICAgICB3cm90ZToNCj4gDQo+ICAgICAgICAg V2h5IGlzIHRoZSBzZXJ2ZXIgcmVqZWN0aW5nIHRoaXMgbWFjID8gc2hvdWxkIE1BQyBiZSBy ZWR1Y2VkIHRvDQo+ICAgICAgICAgMjAgYnl0ZXMgPw0KPiANCj4gDQo+ICAgICBUaGUgTUFD IGlzIHRvbyBsb25nIGFuZCBpdCBzaG91bGQgYmUgdHJ1Y2F0ZWQgdG8gMTYgb3IgMjAgYnl0 ZXMgbG9uZy4NCj4gDQo+ICAgICAgICAgV2h5IGlzIHRoZSBzYW1lIHAxOCB2ZXJzaW9uIGlu IGNsaWVudCBhbmQgc2VydmVyIG5vdCBjb21wYXRpYmxlID8NCj4gDQo+IA0KPiAgICAgSSBk byBub3Qga25vdywgbXkgYmVzdCBndWVzcyBpcyB0aGF0IHRoZSBjb2RlIG1pc3NlZCBhIHRy dW5jYXRpb24uDQo+IA0KDQotLSANCk1hcnRpbiBCdXJuaWNraQ0KDQpTZW5pb3IgU29mdHdh cmUgRW5naW5lZXINCg0KRW1haWw6IG1hcnRpbi5idXJuaWNraUBtZWluYmVyZy5kZQ0KUGhv bmU6ICs0OSA1MjgxIDkzMDktNDE0DQpMaW5rZWRpbjogaHR0cHM6Ly93d3cubGlua2VkaW4u Y29tL2luL21hcnRpbmJ1cm5pY2tpLw0KDQpNRUlOQkVSRyBGdW5rdWhyZW4gR21iSCAmIENv LiBLRw0KTGFuZ2UgV2FuZCA5DQozMTgxMiBCYWQgUHlybW9udCwgR2VybWFueQ0KDQpSZWdp c3RyeSBDb3VydDogQW10c2dlcmljaHQgSGFubm92ZXIgMTcgSFJBIDEwMDMyMg0KTWFuYWdp bmcgRGlyZWN0b3JzOiBOYXRhbGllIE1laW5iZXJnLCBEYW5pZWwgQm9sZHQsIEFuZHJlIEhh cnRtYW5uLCANCkhlaWtvIEdlcnN0dW5nDQoNCldlYnNpdGVzOiBodHRwczovL3d3dy5tZWlu YmVyZy5kZSAgaHR0cHM6Ly93d3cubWVpbmJlcmdnbG9iYWwuY29tDQoNCk1laW5iZXJnIC0g VGhlIFN5bmNocm9uaXphdGlvbiBFeHBlcnRzLg0KDQo=

--------------Mic94HPB0lo00JkdJjD0Whev--

--------------jCuDCeO0MhdiqXrDrS7Kpdzd
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature.asc"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEB4vtcjCE6s9kni+wQXIcDHUJ+cgFAmjCvd0FAwAAAAAACgkQQXIcDHUJ+chi +RAAgEdqaumUcCQjRmf54Z6YrzpA1mY8l2/DQ601GWzZSFg/a2TPhSeywllRTc5av+1kNfft44pM nhx4uzAvsSCuBCowEAcExtZLR/YjqBLwNmnWlx0MwWDHuoD27PGV7zCzb+6Uv2/xpvmkRgq6vXgZ KDyetX3YWSrIw+j43s2OoEQDwo5baMPUSc1gmBzgbHmc8gasGCkg3UKxDaM/4glCvBRRvNc9kaYR bOlvDNNE/NYr8u/J0W33KF55rOBpA3ISO3cVz/xbFpFnesJjjdqa3a9ZWoUjCSGN6xdiPkg67jmP qBN59KIzQR49g+xMWl9asQhhhuK3eyGKa4DeDKGILnTGBk6RmYoKmm2l+35A6F5ZnUE2rqbClEPU C4CDoOWt3/VeiROFu7Myl7+nf0TdEFUbCDChd70vLIWR/K11IeZOY7UbFoRgnwFlK7LlNdmqK5W0 9zeHL57tpXQLKccEM77VnoWder0IhqB4Zg03Ro/tkN6M+kVQgD29zc32QYW/9AVnB8TKIrmiHo/J 9m4npBpHsLWnvRJYc1Cj857hU7IlLqFb80Vf9uBeJC3qIakrz1iZFV6wckdCXfDsF4Ktd/9py3JP CZEGEIFkAY5zXkxxRcOh+ju6olXY8yMQSB+jUKoD3OIKXZ3lfkr5gQaSzXpzGahmIEH7unHlW8k3 guE=
=PKdj
-----END PGP SIGNATURE-----

--------------jCuDCeO0MhdiqXrDrS7Kpdzd--

--- Synchronet 3.21a-Linux NewsLink 1.2