Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise

Natanael <natanael.l@gmail.com> Thu, 07 May 2020 09:58 UTC

Return-Path: <natanael.l@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 9C0E43A0B2B for <cfrg@ietfa.amsl.com>; Thu, 7 May 2020 02:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 40EXb8PjLXZ0 for <cfrg@ietfa.amsl.com>; Thu, 7 May 2020 02:58:10 -0700 (PDT)
Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 BF5AD3A0B26 for <cfrg@irtf.org>; Thu, 7 May 2020 02:58:09 -0700 (PDT)
Received: by mail-vk1-xa34.google.com with SMTP id j1so1472722vkc.2 for <cfrg@irtf.org>; Thu, 07 May 2020 02:58:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Z9//iP2J/VOkVjKqF60rRpH/vGolZge1ylbtP5RgA0=; b=gdACIs3GOkjfw2sara+DyezBEmxsHAo1ildaA16tV6cJ7f/gx2ekjCcReMUWKDlMGP rCpga6tAoXnPtWj820/kkXVtJPzRkOat+EzAvHVwF1JT4Huf+60rm9d2ahZYpdAjuWXS bCDM7cao5HTVpCwIDMTrSq8muACN/2r2KKwieQCPCnNAzKgPY17zbb5l8q56SA9aFo+z KrXRGGMzpXIk/OHyRJrzfHYxCoY9+m3iNxbLzA/QRCwEdRg8EvIe5B4e2peIWaIQAoKe EJ35UAPtxTcGxnMLrCosgfSVcZ4bmfMQwnXvyvsDn21jk3ULO9rkNydVVsASU5Wpno9B ut+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Z9//iP2J/VOkVjKqF60rRpH/vGolZge1ylbtP5RgA0=; b=GdlgdC2563RU5rzZhuBGJdUvE7wDs+3LBo9W+a/WG6Lx97jUpT00r0L8lJE/Bwd1p0 TO1e9Fn92i0YnQAO9yTn5MxJM/NRfVVMtSbkD2bFOSp/x4zKpX2x780f6w5lZvfkPNrx SWYmIaNOlMziFlW38k0hm9W3xy9IJf8Gf00dUTOwz6E1z1ODeqxHpecBEXQ6k/7hVMji 6VDH3si+pkN2lXXEvAg6wMnI2ON3/d5/S8gGtxm6YOtExnAzI1dq+7ghaqgk8XPBXgZS ylrbsr6EGzNjK4adSOEjDKLoGhUike+D7drafU5xY/jJxjim/ulsiguGwMDUy15j9Nq8 SNnA==
X-Gm-Message-State: AGi0PubPZe2sS8LGLTVuXFyLnH3kfaN6yzCmnfi/KaBiVYttimIG4ByA ScDh1rUE4SaVJPkGPyEvFWOssMLv72w4iCAgHqE=
X-Google-Smtp-Source: APiQypKvBSVE6raewZXUb5iYYPe+sdN3htb/EfXTxRHDZuyXYoxuxFcK+nmPZpE5Z2RRnoJB5fNqv0B10xtKRVKW58E=
X-Received: by 2002:a1f:418c:: with SMTP id o134mr10235772vka.42.1588845488720; Thu, 07 May 2020 02:58:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kr18AP2ya5Pn2VXpt6FLO6vWrFQoXrFni28uYgrJXpFA@mail.gmail.com> <e751f285bc814825b42d39d97a0d84aa@blackberry.com>
In-Reply-To: <e751f285bc814825b42d39d97a0d84aa@blackberry.com>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 7 May 2020 11:57:56 +0200
Message-ID: <CAAt2M1_w+0BsP6M_Kw-PZ5atOCb96ut7b5nL_kfe7mgGsyr6LQ@mail.gmail.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, CFRG <cfrg@irtf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f5520e05a50bea78"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Hld2u32BDJCiRLJgatNEp836gkI>
Subject: Re: [Cfrg] Call for adoption draft-mattsson-cfrg-det-sigs-with-noise
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: Thu, 07 May 2020 09:58:13 -0000

Den ons 6 maj 2020 19:49Dan Brown <danibrown@blackberry.com> skrev:

> It seems fine to adopt this, but a few things should be checked.
>
> Procedurally, randomizing signatures is a **reversal** of CFRG consensus
> towards determinism, so maybe past discussions on CFRG are worth reviewing
> (I have forgotten the arguments). Maybe determinism proponents are too busy
> to check here, and should be briefly queried.
>
>From my reading & in my layman's opinion, the primary goal of deterministic
designs is to reduce the risk of bad entropy sources breaking the system.
So it wouldn't be too much of a change of course when the goal is to
increase robustness of the use of entropy, IMHO. But acknowledging the
change makes sense.

I wonder if some applications of signatures now rely on non-standard,
> off-label properties of signatures, e.g. determinism (or non-determinism
> for older applications).  (Non-standard here means something
>
> different from Goldwasser-Micali-Rivest unforgeability against adaptive
> chosen message attacks.)  For example, maybe EdDSA is somewhere being used
> like a verifiable hash?  (Ok, any verifier reliance on determinism is
> probably insecure, because the signer switch over to non-determinism.)
>

There's a separate class of functions called VRF (verifiable random
functions) that should be used if what you need specifically is something
that is equivalent to reliably deterministic signatures.

I've seen cryptocurrency projects rely on assumptions of deterministic
signatures and getting attacked because of it, but these designs were
flawed from the start and probably shouldn't be catered to. People making
assumptions like this needs to verify if the algorithm / implementation
actually provides those properties before using them. It would be much
better in cases like this to explicitly explain which properties are
provided and which aren't, so that flawed choices like this aren't made by
implementors in the first place.

Should we continue to name these “deterministic” signatures, if the plan is
> to make them non-deterministic?
>
> How about message-dependent signatures, since both components of the
> signature (R,S) will depend on the message? Or message-keyed, to emphase
> that R must depend on M, not just S.  (Multi-word phrases have precedents,
> I am reminded of nonce-misuse resistance, thought does not fit here.)
>

I'm reminded of the term "ciphertext stealing" from the XTS cipher mode.
The signature (it parts of it) always was message dependent, but maybe
"entropy stealing" or similar phrasing could be used since we take secret
randomness from additional sources to make the signature algorithm more
robust.

Maybe a more neutral term like "entropy combining" would work better.
"Entropy combining signatures".

>