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

"Valery Smyslov" <> Thu, 02 February 2017 13:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBF44129444 for <>; Thu, 2 Feb 2017 05:21:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.899
X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vwPLwGElg5Vj for <>; Thu, 2 Feb 2017 05:21:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47BD3129438 for <>; Thu, 2 Feb 2017 05:21:45 -0800 (PST)
Received: by with SMTP id z134so8368673lff.3 for <>; Thu, 02 Feb 2017 05:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Iosnjglxd0xmwBzairWarnNY9u5MMWWWp3/7AKY7fwc=; b=bVyCW/pS8VgYu2dELcD+0xyYerQzoAiPxYPsSCeA3ZDHs3SUVMz3fvb7M44N5MADNI JQOkPqPBe4vGMyoaix1lfidkKyGCgZjlgCh9NehnG4AcsMQqxBKxaSjeccsFJtmdu1iQ 2Z7mYu5dteY8cx+3jtoVm1n1hCba9QyduufqV+qJfmtX2soKUJI1kyBCsdlfzBhM7goZ dVuOC/IKd/kG6jA1hqQHqtqsGtZQAv42bHvoYJRrIIFcJIF7FkSZsBRF1U9ekS9TFjSJ Y4aomMdMRgeajuyzcljuP7453RHZHliKmJO2GXwk7NErl9qeMb9WmI47GTNXti35vof8 Hjkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Iosnjglxd0xmwBzairWarnNY9u5MMWWWp3/7AKY7fwc=; b=KzTNt+5xDCFgDWcEHTHRofkjFP3dsErq90MgC4w/iMMwNqTmeFIANkeMMHSJD2lQyG Y8i+SqM2dCXuEzmqk5Yflo/i/Jxi5vt3yq6k9hVGWee5eTkt5jFQhTAc1UsERycQL8vh 4szK79s3hulUVHcRsAchLzttiUuul3P0zTG/jDh/CnnzOvQCDFunOYjU2o4ugKlgQfWT M67iNdkNVFGYxnSXB1XkiIUsR4hTsUnYlyLNlHe8xgyqV3OEfeBX7qJyodLPOVyvBOSW TT9roVL1YnQJzSTwZkzmNNS5dL/vlRrVdJTKQdaDo2CPes3u9hpU36NFel6MzhuJh4m/ 0uKQ==
X-Gm-Message-State: AIkVDXIO9ABiid74tuIuqH0ABNtwbpd9EiYlqLpczK72jfVYOYGqx42QMidRNufxF5547Q==
X-Received: by with SMTP id h20mr3153721lfg.150.1486041703348; Thu, 02 Feb 2017 05:21:43 -0800 (PST)
Received: from buildpc ([]) by with ESMTPSA id s63sm6639965lja.49.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Feb 2017 05:21:42 -0800 (PST)
From: Valery Smyslov <>
To: 'Stephen Farrell' <>, "''" <>
References: <>
In-Reply-To: <>
Date: Thu, 02 Feb 2017 16:21:43 +0300
Message-ID: <0f8701d27d57$4c802920$e5807b60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQISJ/kYuhxy1GvJcY7laVpklrAigqDWS8TQ
Content-Language: ru
Archived-At: <>
Subject: Re: [Cfrg] erratum for hmac what do we think...
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 13:21:47 -0000

Hi Stephen,

I would let cryptographers decide whether it is a real problem
(I'm not a cryptographer), but the proposed resolution 
will break existing standards and implementations.
For example, in IKEv2 there is a requirement that 
PRFs MUST accept keys of any length and HMAC is widely
used as PRF (e.g. PRF_HMAC_SHA1 is currently MTI).
And since nonces are used as a PRF key for SKEYSEED 
computation in IKEv2, the key may be quite long. 
So, regardless whether this is a real problem,
the proposed resolution looks bad.

Valery Smyslov.

> Hiya,
> There's an erratum posted for hmac [1] where I'd be
> interested in what folks here think.
> I'm unsure if this is a real problem, esp given that
> there are I guess a lot of implementations.
> And even if it were a real problem, I'm not sure we'd
> want that fix.
> Opinions welcome...
> Thanks,
> S.
> [1]
> https://www.rfc-
> ronym=&submitter_name=&stream_name=&submit_date=&presentation=records