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

David Jacobson <dmjacobson@sbcglobal.net> Fri, 03 February 2017 16:15 UTC

Return-Path: <dmjacobson@sbcglobal.net>
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 E1038129C19 for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 08:15:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net
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 jU6UkCp8mG5T for <cfrg@ietfa.amsl.com>; Fri, 3 Feb 2017 08:15:15 -0800 (PST)
Received: from nm24-vm2.access.bullet.mail.bf1.yahoo.com (nm24-vm2.access.bullet.mail.bf1.yahoo.com [216.109.115.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3192712946F for <Cfrg@irtf.org>; Fri, 3 Feb 2017 08:06:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1486137980; bh=58vP7/T4Z/Rrh37svUerLRiXjZ+R2GjtKYEyUSHyKDM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=Z/t50zIpC2TKrrA8gn1csGd1EuSCoHtRz/8svMQAJ3dv7YKjihnPOCDVUcCwJjFFl6Z8k8mLdfnylvs+RrmIMxTSzArc1Xx94xX5uhbnx5tkmrjbRKakfzg2lnnAhZBe9SrIvN2DCNLj407RWfYUnQNbZ0mJ5xxJULV7FV4uNOwHpRTLZJQRMlqP+iJc21ZZlORLuFSDd8LUFuK506NhBbMRb5Uw3Le9SZsfY3Rt5CTbnXDC0MIbtY4rfxeAIsrk7DP3xBhJrGJqUtH+AkAonxPcL2PUqJYmrH/I8lTCN6X2Jfdy0YH70G6cVxj5CB2/Y1zTvJP1iNdoWVJsHm8d1w==
Received: from [66.196.81.158] by nm24.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000
Received: from [98.138.104.98] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000
Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 03 Feb 2017 16:06:20 -0000
X-Yahoo-Newman-Id: 222935.53514.bm@smtp118.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: hSEZXvQVM1mfQ6de5Sc6YO4A3l6gYt1D2T3tXnmnwf6vc0o .PHUK4gX8xXaFHz6yg8oT3YG8TRwI0149vApSY4YQIOUkcbNTDNgZudtI.v8 csT0gziw25F_eKf85t7XKMpXl7dDXVibqPMDGs_avuIhtkudk5YcDxOcXKq_ LjNEjwvLo35nvQk_EguRcEF8eQESre6BMwXfX8ySZnAkAhAfnpXRVfW1AJ6B RTP5yeZWu27M6NE1Bjx944XLBgQfGrvv8k9PpyGFERcdyEtNIoDXVJRdsT47 5yZJyn5gWFoOWJYvwUQfDAO4Z67e3.8PD33m88Djd8O6xNmkcDJNK2Dzk_tp WlbavO8xMY_iljZn8Jz1xRzIUJ6jAwcnTV9omC.adxFzzpiyNXQIMFXxMJcn drK7n796OUl2mZ1grcnVvC0rMbJerQPSZfeh5RJ5tEILeJ34qae1LBCRAAVw Xq54XCK1nCn4x..PgRd3Cr7z.7MV.CfinCvjX3lKH7tGxozXsampi3N3FHUg 529ZNxN7vyByMD6p7PSPMD7NMEEwPNPAKhmfBHxWx2mYF.jIYgK38d6QYUCz mCoGYRZuqLQ--
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Hugo Krawczyk <hugo@ee.technion.ac.il>
References: <666efaf7-b660-e20b-8a8a-8949a64e9bed@cs.tcd.ie> <D4B8ED5B.83EFC%kenny.paterson@rhul.ac.uk> <CAAQpVOhTHLHFKgWYFnhpW7fHju1i5N83yzaR3x4+Ea1+M5hzbQ@mail.gmail.com> <CADi0yUNCXneU4CbWT=KZ6CckR0Dv93XKoAUwRVsskE+MRijOZw@mail.gmail.com> <1486117441931.10734@cs.auckland.ac.nz>
From: David Jacobson <dmjacobson@sbcglobal.net>
Message-ID: <3af52483-3793-91cc-54e4-dc383748e713@sbcglobal.net>
Date: Fri, 3 Feb 2017 08:06:18 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <1486117441931.10734@cs.auckland.ac.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/7sQ7BGtbdx7f0NVEYSNs5ufVAvs>
Cc: "cfrg@irtf.org" <Cfrg@irtf.org>
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 16:15:16 -0000

On 2/3/17 2:24 AM, Peter Gutmann wrote:
> Hugo Krawczyk <hugo@ee.technion.ac.il> writes:
>
>> For example, people wanted to use unlimited passphrases, and between having
>> people truncate long keys or hash them first, the latter seemed the more
>> robust solution. (BTW, the right way to deal with these issues using HMAC is
>> to use HKDF.)
> Another solution to the fact that there are two external-format keys that map
> to a single internal-format key (i.e. the > blocksize key and its hash) would
> be to reserve the first bit of the internal-format key to denote hashed vs.
> non-hashed.  OTOH then people would complain about losing one bit of strength,
> or someone would propose an attack based on knowing that the first bit will
> almost always be zero (for non-hashed), or something similar.  You can't win
> :-).
>
> Peter.
Okay, we're off on a tangent and into hypotheticals about what could be 
done, so I'll make two suggestions.  They could be used separately or 
together.

1.  The present scheme uses an OPAD of 3636...  .  Instead use 3636... 
when no hashing is done and, say, a9a9... when hashing is done.

2.  In addition to XORing the key with the OPAD, also XOR (at the right 
of the first block) with the length of the key in in bits (or bytes).

    --David Jacobson