IETF Logo Mail Archive

Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...

"Dang, Quynh (Fed)" <quynh.dang@nist.gov> Wed, 08 February 2017 13:31 UTC

Return-Path: <quynh.dang@nist.gov>
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 03B4B129A49 for <cfrg@ietfa.amsl.com>; Wed, 8 Feb 2017 05:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com
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 XHS1n3XjVjJ8 for <cfrg@ietfa.amsl.com>; Wed, 8 Feb 2017 05:31:25 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0108.outbound.protection.outlook.com [23.103.201.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E88129A43 for <cfrg@ietf.org>; Wed, 8 Feb 2017 05:31:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BjE/tVKaD94vNWUs7xxFUnh5fySguvQiARMXr/PGfVU=; b=hUi0itQKIn1WDPD/C2nfazoewvwHV+cbD7IkUxS+5JwojqqfgZLGSLH7Cm3qbx/5mfL1QRORdz+VfudxHxX2vazAcjbatse1rj9ffcJC0w7PRzzWVPTPheUh+QL0NYWyMK1CQWpGa9runpV7UfnpooknOvQ7dT4Z7vbf9jIODBc=
Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 13:31:22 +0000
Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 13:31:22 +0000
From: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
To: Randal Atkinson <randal.atkinson.ctr@nrl.navy.mil>, Michael StJohns <msj@nthpermutation.com>, "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Thread-Topic: Aside Re: [CFRG] erratum for hmac ...
Thread-Index: AQHSgWiX/QOHsp+cqk6PweDPw/SKDKFfEXKk
Date: Wed, 08 Feb 2017 13:31:22 +0000
Message-ID: <CY4PR09MB1464F9936D5C07DF16D29403F3420@CY4PR09MB1464.namprd09.prod.outlook.com>
References: <F2C52E74-6FF0-4F72-BFD0-56D39031B4D9@nrl.navy.mil>
In-Reply-To: <F2C52E74-6FF0-4F72-BFD0-56D39031B4D9@nrl.navy.mil>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.219.23]
x-ms-office365-filtering-correlation-id: b3060307-9cc4-4572-1d3c-08d45026c61a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR09MB1464;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:0q/fTSzatPSU69UTVtIVmtJbVex0AxYYMLbq1gRGxl+e8OnbIK2TLZK6eh8pQeaIMtmsuyTFmYKOlgIUWnkc/eUGvXYoyspOegeBTyoAH8al2tiH+futRufqO4Pgt2c0hmkuIo31p9aSrzd7Q37otLjjpnHFQ3i3iAk4IaP+6Sjb5sH2qrGA60YD9UfO2bqKAYuyaH3rzJHZrrkA/x7eVyK2Aj02lustWwV40uGhaRoTZqkraAO7iiahr9llERHG8+oUagpETTnV1uivkE0lYb4artQsYMsYTAj8djtGmneAScEMMFgoNLNJCivke0C/B3bs8hfFdbPs356JL7gh3fef08UymwoBsMnZVmfN8doRPhFi+2zIfQaIfq3l0Z1h1euDK9mlvgi2fOqK/jxoNh/VSXUDLq7kxzfP3ST4xH6aDsbxTTWrmR+I6q0RwN285gWxeADgTuNHj2Xp8jE1wSUGXRqUwTODHZYq9F8CpJdUxAAMF04gKQs9CDGWSTboVoFmNKEeyTdU4LdcIXPsGA==
x-microsoft-antispam-prvs: <CY4PR09MB1464F21119EB4E07BD5A438CF3420@CY4PR09MB1464.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(4659246709749);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(2017020702029)(20170203043)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(377454003)(189002)(199003)(9686003)(6246003)(2906002)(53546003)(74316002)(81166006)(38730400002)(6436002)(66066001)(229853002)(6506006)(6116002)(3846002)(102836003)(8656002)(101416001)(25786008)(54896002)(8936002)(7736002)(33656002)(8676002)(77096006)(81156014)(3660700001)(53936002)(55016002)(2900100001)(99286003)(7696004)(92566002)(189998001)(68736007)(76176999)(6606003)(54356999)(4326007)(3280700002)(5660300001)(122556002)(106116001)(19627405001)(105586002)(97736004)(106356001)(86362001)(2950100002)(50986999)(345774005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB1464F9936D5C07DF16D29403F3420CY4PR09MB1464namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 13:31:22.7120 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bJ-Y6KikqWXxsxOrp_BhYqEKPQ8>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [Cfrg] Aside Re: [CFRG] erratum for hmac ...
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: Wed, 08 Feb 2017 13:31:30 -0000

Randal, Michael and many others,


Thank you for your suggestions.


Kenny,


Thank you for your discussion email.


We are thinking about what would be the best option for HMAC.  Some technical possibilities are below.


1) Don't change the HMAC spec.

Ask a HMAC key always to have a fixed length such as HMAC-SHA256 having 256-bit key. Which means that all protocols using HMAC-SHA256 use 256-bit keys.

If each protocol uses a different key length, then the issue would still exist across protocols. I don't know if this is a practical security problem, but it seems like a problem that should be avoided.

Should ask HMAC keys to be processed/produced by a hash function or another PRF always.

This option does not break interoperability of  the current HMAC implementations.

2) Change the HMAC Spec.

a) Always hash the key regardless of its length, then perform step 3 in FIPS 198.
b) Use a hash-based KDF (not HKDF) to produce B bits from the key, then go to step 4 in the FIPS. (bad for performance).
c) Require key < B, then do multi-rate padding 10* to make the key B bits, then go to step 4 in the FIPS. (good for performance).

We recommend the use of KMAC in SP 800-185. KMAC's security is solid and proven, and it has great performance. Code to implement KMAC can be reused to implement many other Keccak-derived symmetric-key crypto functions.

Regards,
Quynh.
________________________________
From: Randal Atkinson <randal.atkinson.ctr@nrl.navy.mil>
Sent: Tuesday, February 7, 2017 12:34 PM
To: Dang, Quynh (Fed)
Cc: Randal Atkinson
Subject: Aside Re: [CFRG] erratum for hmac ...


One option available to NIST would be for NIST to open comments
on updating FIPS 198-1, even if opening comments on that now/soon
would be earlier than NIST ordinarily would do so.

Given how long it takes to move from an approved FIPS revision
to widespread US Government deployment, if data exists from
Kenny P and/or others that merits an update, then starting sooner
would not be a bad thing for the USG.

Cheers,

Ran Atkinson

--------------------------------
Randal Atkinson, PhD
Cheltenham Research for NRL 5520
randal.atkinson.ctr@nrl.navy.mil

v2.23.0 | Report a Bug | By Email