Return-Path: From: Kalle Valo To: Arend van Spriel Cc: Emil Lenngren , Emmanuel Grumbach , Kees Cook , "Jason A. Donenfeld" , LKML , "kernel-hardening\@lists.openwall.com" , 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 , keyrings@vger.kernel.org, Bluez mailing list , "open list\:NFS\, SUNRPC\, AND..." , linux-wireless , Network Development Subject: Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important References: <20170610025912.6499-1-Jason@zx2c4.com> <878tkzq6wi.fsf@purkki.adurom.net>

<5595d4bc-a43e-7a89-eb86-fa77556cd7af@broadcom.com> Date: Mon, 12 Jun 2017 16:46:47 +0300 In-Reply-To: <5595d4bc-a43e-7a89-eb86-fa77556cd7af@broadcom.com> (Arend van Spriel's message of "Mon, 12 Jun 2017 09:33:24 +0200") Message-ID: <87lgox8gjc.fsf@kamboji.qca.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain List-ID: 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: >>>> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html >>>> >>> >>> 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 helpful. -- Kalle Valo