Re: [CFRG] Extract-and-expand with KMAC

"rsw@jfet.org" <rsw@jfet.org> Wed, 18 November 2020 19:05 UTC

Return-Path: <rswatjfet.org@gmail.com>
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 ADC583A09D3 for <cfrg@ietfa.amsl.com>; Wed, 18 Nov 2020 11:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 NjkkScG0Br5s for <cfrg@ietfa.amsl.com>; Wed, 18 Nov 2020 11:05:56 -0800 (PST)
Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (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 9B6593A09D4 for <cfrg@irtf.org>; Wed, 18 Nov 2020 11:05:54 -0800 (PST)
Received: by mail-qk1-f181.google.com with SMTP id u4so2878838qkk.10 for <cfrg@irtf.org>; Wed, 18 Nov 2020 11:05:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sHrr1dzJIdIIAWboyYejYA32w1VhSKlpJBam97vRjGE=; b=lsieS6H8WMKKL/0a3r7gXeWiesGH19qBQEbqXmPf7cwOAWttoL3aNnI8ts5m03YRfb lvoHqR5WpRg82xNxEjPNimPGyE53clKSiShaalEkqL7U+MN912pstvrRLo2ZZM4e1MR7 MEzlWOumNhkBgM9RF9kv5XuOfqiW3ggOST0xmWHTuqt5usYV+jQNgsH3pHrvc+0M7glb ToSsOEhyGLNBgwcdOLg6e0HlmLZ+ikPg8kbIXB35ZQDKgDpJopFrhHVC9o1iInMhuDb6 KSGqzI8cr2NQHaxOjcOevXFE0f71Go8sOIAjmhp86jfeJxQvr1jWn5PRpZxXSK+e4MFQ 5K8Q==
X-Gm-Message-State: AOAM531evpFnRPYokP7WyEAQaVhrDmT3INDsw8WL5R++ljMd5MXNY9DD BKeM28303srqVBXVurQ0QJY=
X-Google-Smtp-Source: ABdhPJy/BjHZzpmfiJ86nNh6vQeWCqTMj+Sp1Pxua+cIZgbt29VSL4cssd8WkrP5PJYsNgV/EaCevA==
X-Received: by 2002:a37:444d:: with SMTP id r74mr6665321qka.105.1605726353695; Wed, 18 Nov 2020 11:05:53 -0800 (PST)
Received: from localhost (76-226-64-225.lightspeed.sntcca.sbcglobal.net. [76.226.64.225]) by smtp.gmail.com with ESMTPSA id k70sm17654133qke.46.2020.11.18.11.05.51 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Nov 2020 11:05:52 -0800 (PST)
Date: Wed, 18 Nov 2020 11:05:50 -0800
From: "rsw@jfet.org" <rsw@jfet.org>
To: "Dang, Quynh H. (Fed)" <quynh.dang@nist.gov>
Cc: Gilles VAN ASSCHE <gilles.vanassche@st.com>, CFRG <cfrg@irtf.org>
Message-ID: <20201118190550.hzpggpt5a367auik@muon>
References: <467DD0FC-FF7F-453F-98B2-ADC7F0F976B1@ericsson.com> <20201115163535.GA3384456@LK-Perkele-VII> <AM9PR10MB43541E50ABC210C17630FBFCF2E10@AM9PR10MB4354.EURPRD10.PROD.OUTLOOK.COM> <20201118175330.nt4nb4jqvzsjtmjw@muon> <SA0PR09MB68410F90BBD3A5D45FF5E858F3E10@SA0PR09MB6841.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <SA0PR09MB68410F90BBD3A5D45FF5E858F3E10@SA0PR09MB6841.namprd09.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ekAEsA2ZNBa_MywLm5Vj8MPW5Gg>
Subject: Re: [CFRG] Extract-and-expand with KMAC
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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, 18 Nov 2020 19:05:58 -0000

Hi Quynh,

"Dang, Quynh H. (Fed)" <quynh.dang@nist.gov> wrote:
> I am not aware of a protocol where the output from an extract step:
> PRK is saved and the expansion step gets executed later to generate
> keys.

Totally agreed! in most cases, we don't worry much about PRK. Note,
however, that the message I was responding to explicitly *did* worry
about it:

Gilles VAN ASSCHE <gilles.vanassche@st.com> wrote:
> This solution is not incompatible with the case where an intermediate
> value PRK is required:

If indeed the intermediate value is required, as discussed here, then
my concerns about non--black-box use of the primitives are relevant.
Otherwise, as you say, no worries at all---and we have good reason
to believe that constructions like SHA-3 are great for such cases.

Best,

-=rsw