Re: [Cfrg] erratum for hmac what do we think...

Ann <a.yousar@informatik.hu-berlin.de> Fri, 03 February 2017 10:23 UTC

Return-Path: <a.yousar@informatik.hu-berlin.de>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12800129BCB for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 02:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=informatik.hu-berlin.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ9052GhIa6g for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 02:23:46 -0800 (PST)
Received: from mailout1.informatik.hu-berlin.de (mailout1.informatik.hu-berlin.de [141.20.20.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56938129BDF for <cfrg@irtf.org>; Fri, 3 Feb 2017 02:23:42 -0800 (PST)
Received: from mailbox.informatik.hu-berlin.de (mailbox [141.20.20.63]) by mail.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-25) with ESMTP id v13ANcOx011221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <cfrg@irtf.org>; Fri, 3 Feb 2017 11:23:39 +0100 (MET)
Received: from [192.168.178.106] (p5085BC75.dip0.t-ipconnect.de [80.133.188.117]) (authenticated bits=0) by mailbox.informatik.hu-berlin.de (8.14.7/8.14.7/INF-2.0-MA-SOLARIS-2.10-AUTH-26-465-587) with ESMTP id v13ANaXn011205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <cfrg@irtf.org>; Fri, 3 Feb 2017 11:23:38 +0100 (MET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=informatik.hu-berlin.de; s=mailbox; t=1486117418; bh=zmOODTSxwKiJQRhwD+dzZsAzdekFm0kosA6mdYC7Ebw=; h=Subject:To:References:From:Date:In-Reply-To; b=AZVoJ5kHPHZrdLgNnCA6EDGU7Argq6AoOkCQIqCS9jnYYkG1wgNylaEOtp4dDkIqb 0IL+cbpNkvISOoVuBXYjgnQIotu4F1Y8a06L0zD7KnIWSrRyMhqzTcU2LLAhnKYvlg l25nOiGcEY9cBLcdSFcswvRL0dE1BwvkHtvZkjK8=
To: cfrg@irtf.org
References: <20170202215631.7D72A60AA2@jupiter.mumble.net>
From: Ann <a.yousar@informatik.hu-berlin.de>
Message-ID: <58945A2E.7000606@informatik.hu-berlin.de>
Date: Fri, 3 Feb 2017 11:23:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20170202215631.7D72A60AA2@jupiter.mumble.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.4 at mailbox
X-Virus-Status: Clean
X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.5.1 (mail.informatik.hu-berlin.de [141.20.20.50]); Fri, 03 Feb 2017 11:23:39 +0100 (MET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/aVvJ5h87Mxlxtbx678yFqFrx52c>
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 10:23:48 -0000

Anyway, the actual text is prone to HMACcollisions:
Given |k|<b one can find easily another k' with HMAC-H_h = HMAC-H_k.
Why not accept this issue as an erratum of the RFC?

Not sure that the prosed correction is necessary. You gave some
considerations to reject it.
My 2 cents: you should write "MUST NOT" instead of "MUST not" ;-)

Regards,
/Ann.


Am 02.02.2017 um 22:56 schrieb Taylor R Campbell:
>> Date: Thu, 2 Feb 2017 02:24:44 +0000
>> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
>>
>> There's an erratum posted for hmac [1] where I'd be
>> interested in what folks here think.
> Fix hash function H with block size b.  The alleged problem is that
> for a key k, if |k| > b and h = H(k), then HMAC-H_h = HMAC-H_k.
>
> What protocol would ever use HMAC-H with related keys of different
> lengths like this for the same purpose?  What protocol would ever use
> HMAC-H with keys of different lengths at all for the same purpose?
>
> Needless flexibility like that strikes me as more likely to indicate a
> deeper problem -- e.g., one reason that might happen is that the
> protocol foolishly uses a password verbatim as an HMAC key.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg