Re: [Cfrg] My thoughts on randomized signature generation

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 11 May 2020 17:44 UTC

Return-Path: <hallam@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 69E773A0AA4 for <cfrg@ietfa.amsl.com>; Mon, 11 May 2020 10:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.396
X-Spam-Level:
X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 HwNB3GOSiAHB for <cfrg@ietfa.amsl.com>; Mon, 11 May 2020 10:44:25 -0700 (PDT)
Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) (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 60C703A0854 for <cfrg@irtf.org>; Mon, 11 May 2020 10:44:25 -0700 (PDT)
Received: by mail-oo1-f48.google.com with SMTP id r1so2120881oog.7 for <cfrg@irtf.org>; Mon, 11 May 2020 10:44:25 -0700 (PDT)
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=DYu+KTUhIS095RBssMHeoTPicmBiUtE0rn+BkjP6Vi8=; b=osbDMdL+x5UaOzL6vXlCBTETDh4lSOmTLqBiCjnUFCWj3RiiVKHSRp3g8IaV+Wfwsk CjFIxUnBH+IsI5m3wS7JvcfBLONSPaKGzY9lOKn9k4XIhq0kE/B+bzYyS3epmzWaeIk5 gnjDKyuMfYn1/Bhhj2BF4LmZ372ZR6colEs9GhuRNT2yiQcSZRdNRS+hcbBgejajkiJP vUpoC4jzR5Hhv8NiO8xuDZSUMK4AEeoBwHvr1vWc1Ibn6NJ6iPvLoYHzVSCpqIuBosaD 87y2G0Rb+xW7iMUtTXIbdXXdqKPbbGiePsxUFg7H5v6RpEKlsWiXWMHrHO/fQPFbGiNW YxgA==
X-Gm-Message-State: AGi0PuajMxc2VO9tTE5OpuJG1SieHOVymWtJqH+bG3biK2XVap9zHIhk STy+CjYGEnI3Zc2GAMqk98IRvyS01myDTXhsMls=
X-Google-Smtp-Source: APiQypIesuqtAl718GUoU3XU/B/0/qv/UZQfE34yQkPQee8DrhYZcwRtFLKH11JMegg54u9smeblXttawZEaliIzGNc=
X-Received: by 2002:a4a:c886:: with SMTP id t6mr867689ooq.92.1589219064585; Mon, 11 May 2020 10:44:24 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0c=8TTmh=_Zbf170sSxDHkSyzeTsvp2g=KZm4U19LCb7eQ@mail.gmail.com> <ef01dadc-0f06-d833-e37e-08cf74c3134d@riseup.net>
In-Reply-To: <ef01dadc-0f06-d833-e37e-08cf74c3134d@riseup.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 11 May 2020 13:44:13 -0400
Message-ID: <CAMm+Lwh1KiAuRGs6SFJ5rrxhBB_xkReDpcMbzDmorFSX53xsyw@mail.gmail.com>
To: =?UTF-8?Q?Sof=C3=ADa_Celi?= <cherenkov@riseup.net>
Cc: IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000d0a2e705a562e526"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/-ItMSHy-y1B8chTROAMIxTgsl-Q>
Subject: Re: [Cfrg] My thoughts on randomized signature generation
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: Mon, 11 May 2020 17:44:33 -0000

On Fri, May 8, 2020 at 10:33 AM Sofía Celi <cherenkov@riseup.net> wrote:

> Hi, Watson and list,
>
> Thanks so much for sending this.
>
> I agree with Watson on the problems that this will introduce, and that
> this have to be taken into account carefully.
>
> I'll also like to raise some doubts around introducing this for RFC8032.
> That RFC specifies already certain security recommendations for
> side-channel leaks and as well as randomness considerations in what
> seems to concern the RFC. The RFC seems also to concern only about the
> algorithm itself, and just expects the private key to be
> cryptographically secure random data, following RFC4086. I haven't
> correctly reviewed RFC4086, but maybe this can be the place to correctly
> define the requirements for randomness, specifically for IoT deployments.
>

Correctly stated, the requirement is for unguessability, not randomness.

That it is random is a necessary but not sufficient condition. It is the
unguessable part that is hard.

One approach that I think lends itself very well is to make use of a KDF
over a device specific secret with the salt input including a counter
value. But for robustness, I would also want a value depending on the key
pair, the purported date time, etc. etc.


At the end of the day, if the attacker knows the initial internal state of
the device and all the communications between the device and the outside
world, they are going to be able to emulate that device.