Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Jun 2017 16:46:47 +0300
From: Kalle Valo <>
To: Arend van Spriel <>
Cc: Emil Lenngren <>,  Emmanuel Grumbach <>,  Kees Cook <>,  "Jason A. Donenfeld" <>,  LKML <>,  "kernel-hardening\" <>,  Anna Schumaker <>,  David Howells <>,  David Safford <>,  "David S. Miller" <>,  Gilad Ben-Yossef <>,  Greg Kroah-Hartman <>,  Gustavo Padovan <>,  "J. Bruce Fields" <>,  Jeff Layton <>,  Johan Hedberg <>,  Johannes Berg <>,  Marcel Holtmann <>,  Mimi Zohar <>,  Trond Myklebust <>,,  Bluez mailing list <>,  "open list\:NFS\, SUNRPC\, AND..." <linu>,  linux-wireless <>,  Network Development <>
Subject: Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important

Arend van Spriel <> writes:

> On 6/11/2017 11:30 PM, Emil Lenngren wrote:
>> 2017-06-11 22:48 GMT+02:00 Emmanuel Grumbach <>:
>>> On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook <> wrote:
>>>> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo <> wrote:
>>>>> "Jason A. Donenfeld" <> writes:
>>>>>> Whenever you're comparing two MACs, it's important to do this using
>>>>>> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
>>>>>> which could then be used to iteratively forge a MAC.
>>>>> Do you have any pointers where I could learn more about this?
>>>> While not using C specifically, this talks about the problem generally:
>>> Sorry for the stupid question, but the MAC address is in plaintext in
>>> the air anyway or easily accessible via user space tools. I fail to
>>> see what it is so secret about a MAC address in that code where that
>>> same MAC address is accessible via myriads of ways.
>> I think you're mixing up Media Access Control (MAC) addresses with
>> Message Authentication Code (MAC). The second one is a cryptographic
>> signature of a message.
> While this may be obvious to those who are in the know this mixup is
> easily made outside the crypto domain and especially in the (wireless)
> networking domain (my mind wandered towards the same error path).

I did realise that this was about Message Authentication Code (yay!) but
I got lost because I thought this is somehow related to timestamps :)
Thanks to Kees I now understand this is about revealing execution time
to the attacker, not timestamps or anything like that.

> As this series is touching stuff outside crypto it is good to be
> explicit and not use such abbreviations that can be misinterpreted.
> The article Kees referred to is also useful to get into the proper
> context here and at least worth mentioning this or other useful
> references in the cover letter.

And the kernel documentation we have is not really helping much:

 * crypto_memneq - Compare two areas of memory without leaking
 *		   timing information.
 * @a: One area of memory
 * @b: Another area of memory
 * @size: The size of the area.
 * Returns 0 when data is equal, 1 otherwise.

For most people "leaking timing information" does not tell much. Adding
a sentence or two _why_ this function should be used would be very

Kalle Valo

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.