On Thu, Mar 01, 2018 at 02:36:45PM -0800, Hal Murray wrote:
> > As I understand it, the main advantage is better performance (when
> > implemented properly). For instance, on a server configured with a SHA256
> > key I'm observing a 40% drop in performance when compared to no
> > authentication. With AES-CMAC the impact should be much smaller. I've not
> > tried it yet.
> How are you measuring performance?
I was measuring the maximum rate of requests the NTP server could
handle, so that includes all overhead of receiving and sending
packets in the OS, etc.
> My measurements are that the CMAC part is 696 ns in software and 499 ns with
> AES-NI. That was on a 2+ GHz cloud server. (None of my handy boxes have
> AES-NI.) SHA512 was 594 with 16 or 20 byte key and 624/614 with 24/32 byte
> keys. That's just the crypto part to compute the digest.
Does that include the time spent in allocation of the CMAC context and
the initialization with the key? I think an optimized implementation
could avoid both. (With the old MAC the key has to be hashed with each
Anyway, older versions of the ntp-mac draft included some measurements
of latency and throughput, which showed that with AES-NI the CMAC is
significantly faster than MD5, which should be significantly faster
I think the only downside of AES-CMAC is that it is not widely
supported in crypto libraries yet. OpenSSL seems to be an exception.
TICTOC mailing list