Re: [Cfrg] Deterministic signatures, revisit?

denis bider <> Tue, 10 October 2017 04:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F33D13207A for <>; Mon, 9 Oct 2017 21:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RJSZy9X7RERE for <>; Mon, 9 Oct 2017 21:01:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35890120720 for <>; Mon, 9 Oct 2017 21:01:36 -0700 (PDT)
Received: by with SMTP id a69so6466979lfe.5 for <>; Mon, 09 Oct 2017 21:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jPvEjVFUkeenw7nDullIw5WGEpCL8Xci4iUcI0/Rglo=; b=D7/NtjCxq2qL2j0Vllfele2T+UiygUfj/WMto3xFv9dZS5XCMNZ3Rn1ZFtrSDckweZ ClIpLUz2sOVy1RWTO3SZcpaGjJxZH0AWvZ/hQfehZybdQg9RrcVlYoGu0RftieINc4dn zWo9zQ7Z32tNfagWfJfgKdQNVPNmdLoCpYoCHwKpeYeIhXDyl7pBQIz8MBRxeQWf+AwN zuhvpx0ypakK/tAVr073qYsS0guBuPTeBi3TOca4h6IdmMMzrCNTWl3Wgd18KOoE5i6H rAlzwT8XFTRKMhV2cnxb0D8+KVjVQ2ir/l5ODqde6u+SaX0iC6EG7b+OaJSuMYjusIAB Ug8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jPvEjVFUkeenw7nDullIw5WGEpCL8Xci4iUcI0/Rglo=; b=Q4fs5guNn5numZb8xx81yLKoVQd5F8JhbC21g1ppBWC6PErO/WfxbW6S3H8HShRYdB SiCxMaHaW1YD3eju20q5jwhGQGYYTOYi6q3oe/49DuXsh5/n2ub+mqkQkeGbs4oMhFuw kEpEop9MZxN93n8jDLHy4IYAw5ybimejKnlOb9iQh0gclzYHKoxRcANG9KbiPYHeZmxv ZCwiz4CRqloowfjQCCF9NkNfGw87gu06ZoUmQStXtId9JN8wx5ivZdPZJhlCv+8N7trf yZ/+ha6eqR2w8KCDvwEYU7Mnfpd6tItJPQHlmoEA+bMTdMFmuWjhooZCQpmElX/YJsZD fwKg==
X-Gm-Message-State: AMCzsaWpFh3tG92cgUgjiII+MMl4f6JvyDGZRUDGU/1t38zpSVDNUCb2 H1VUad7oB5lVMJz6xw8/hrKOboOHYem5Q1qMBSA=
X-Google-Smtp-Source: AOwi7QDH+Fvxn9+8NjGSDuM3sqKw58Un2s6w47AvYceHrZuGku6dZs9frkdORTC0Dr2lI8dCFNH14seC4UTNVFbZEw8=
X-Received: by with SMTP id f12mr5338852lja.106.1507608094211; Mon, 09 Oct 2017 21:01:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 9 Oct 2017 21:01:33 -0700 (PDT)
From: denis bider <>
Date: Mon, 09 Oct 2017 23:01:33 -0500
Message-ID: <>
To: Cfrg <>
Content-Type: multipart/alternative; boundary="089e0823dca4ea80b4055b295c79"
Archived-At: <>
Subject: Re: [Cfrg] Deterministic signatures, revisit?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Oct 2017 04:01:38 -0000

Aren't the devices that are most susceptible to fault injection also least
likely to implement a secure PRNG? My understanding is that these might be
embedded devices, which often use PRNG based on a seed that's a simple
timestamp, or even a hardcoded seed.

Deterministic signatures have the property of being deterministic, i.e.
there's a 1-to-1 mapping between { message, key } and { signature }. This
makes the signing process idempotent, which could be useful in distributed
systems. The deterministic property might also be welcome in forensics.

Is it not cost-effective, or safe, to add mitigations such as the device
verifying the signature, or the results of intermediate steps, before
releasing the signature?

If such mitigations are not viable, is injecting randomness into the
signing process effective, if the devices most susceptible to fault
injection are also likely to implement insecure PRNG?

----- Original Message -----
From: Tony Arcieri
Sent: Monday, October 9, 2017 12:30
To: Dan Brown
Cc: Cfrg
Subject: Re: [Cfrg] Deterministic signatures, revisit?

This certainly keeps coming up. Beyond those papers see the previous "Side
channel attack and Edwards curves" thread on this list:

I think it's definitely a problem that needs to be addressed. I've seen
various proposals to do so as well, i.e. synthesizing "r" as a combination
of a random nonce and the message, so that fault attacks would, at the very
least, require an RNG failure as opposed to always being possible, due to
repeated "r" values for the same message. This should retain the extant
defense against RNG failures in general as we saw with ECDSA "k" values,
since it would still include hashing the message as part of the calculation.

Tony Arcieri

Cfrg mailing list