Hi Daniel, On Wed, Feb 28, 2018 at 08:51:30AM -0500, Daniel Franke wrote: > The block size of AES is 128 bits, regardless of whether a 128- or 256-bit > key is used, and therefore the output of AES-CMAC is always 128 bits. > 160-bit digests are already supported by RFC7822, but there's no way to > make AES-CMAC produce one.
Understood. Thanks for reminding me that RFC7822 explicitly updates the acceptable digest sizes to be 4, 20, or 24 octets long (inclusive of the 4 octet key id). Given that, should I interpret "the resulting MAC tag SHOULD be 128 bits long" as, "When using draft-ietf-ntp-mac-03 authentication, the MAC tag must be either 0-bits (Crypto-NAK) or 128-bits (AES-CMAC) long. Otherwise, see RFC 7822."? >>> Forgive me if this has been discussed and I missed it. But, to >>> improve quantum resistance should the draft recommend AES-256 over >>> AES-128? I realize that the RFC 4493 construction specifically uses >>> AES-128, but is there any barrier to using AES-256? Do you happen to know the rationale for recommending AES-128 over AES-256? It seems like it would be appropriate to default to the more secure variant since implementations MAY always choose AES-128 as long as they understand the security implications of doing so. Thanks, Matt > > On Feb 28, 2018 7:47 AM, "Harlan Stenn" <[email protected]> wrote: > > > Most everybody seems to think that 160 bits of digest is all that will > > ever be needed. > > > > I'm perfectly happy making sure longer digests are supported. > > -- Harlan Stenn <[email protected]> > > http://networktimefoundation.org - be a member! > > > > _______________________________________________ > > ntp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ntp > >
signature.asc
Description: PGP signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
