Hi Miroslav,

On Fri, Mar 02, 2018 at 10:11:45AM +0100, Miroslav Lichvar wrote:
> On Thu, Mar 01, 2018 at 06:40:45PM -0500, Matthew Van Gundy wrote:
> > On Wed, Feb 28, 2018 at 11:06:36PM -0800, Hal Murray wrote:
> > > Why is AES-CMAC more interesting than one of the digests supported by 
> > > OpenSSL?
> > 
> > The keyed-hash construction that NTP uses is not a secure message
> > authentication code, it is vulnerable to the classic length extension
> > attack [1] when used with common hash functions, such as MD5, SHA-1,
> > and the SHA-2 family of hash functions.  This allows an attacker to
> > append additional forged NTPv4 extension fields on to an authenticated
> > NTPv4 packet.
> Does this actually apply to NTPv4? Do you have any examples how could
> an attacker append a valid extension field to an NTPv4 packet?
> My understanding is that the NTPv4 packet format (with or without
> RFC7822) prevents the length-extension attack as extension fields
> cannot have a length of zero, which would come from the padding
> (always starting with 0x80000000). Even if the length field could be
> zero, there is no EF type 0x8000 assigned yet and it could be avoided
> in future in case people are for some reason still using the old MAC.

I was speaking in general terms. I have not actually proved out an
attack against an NTPv4 implementation.  I believe you are correct:
since most hash functions in common use pad the last block with a
binary string beginning with 0x80000000 or 0x00000000, an NTPv4
implementation would parse a length extended packet as an extension of
length zero, and would probably discard it (or fail to process
additional extensions in a meaningful way).

However, there is no requirement that hash functions pad the last
block with any specific value.  Though it may be unlikely, this is a
brittle assumption that could be invalidated by future hash functions.
Using secure message authentication codes such as CMAC or HMAC avoids
this potential failure case.


Attachment: signature.asc
Description: PGP signature

TICTOC mailing list

Reply via email to