Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752273AbdFLFDk (ORCPT ); Mon, 12 Jun 2017 01:03:40 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:33712 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238AbdFLFDf (ORCPT ); Mon, 12 Jun 2017 01:03:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170610025912.6499-1-Jason@zx2c4.com> <878tkzq6wi.fsf@purkki.adurom.net> From: Emmanuel Grumbach Date: Mon, 12 Jun 2017 08:03:33 +0300 Message-ID: Subject: Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important To: Emil Lenngren Cc: Kees Cook , Kalle Valo , "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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1313 Lines: 27 On Mon, Jun 12, 2017 at 12:30 AM, 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. Obviously... Sorry for the noise.