Re: [CFRG] Threshold Sig required - Random bit flip hits Cert Transparency Log

Phillip Hallam-Baker <> Thu, 08 July 2021 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11D973A2619 for <>; Thu, 8 Jul 2021 08:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ELfLRzNkJrul for <>; Thu, 8 Jul 2021 08:58:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B8943A2613 for <>; Thu, 8 Jul 2021 08:58:58 -0700 (PDT)
Received: by with SMTP id y38so9742638ybi.1 for <>; Thu, 08 Jul 2021 08:58:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m2JpJcRvvmDswAlelP3TTbB8WbwsK7Y5ZlpLCl2bH/A=; b=m+8r3DFGwTrk6KHMc66TIVRSf6k/M19u4xnIHGnG2Gg18imDS/bnVoV0pTmhQiFAZJ cTD6/3N1c2wYWYjTzZOlVPrKuXlXHgzPmZ/qpMJjmIjwrUXlRhCJuCVZ3r7NTGOhrJtE lH6dr0LHrilXz0PYe8dNWCu6AWIwWCYX0hpJAMn8tIeRb7u3LBQt3S5BPw/Zwn99TzfQ i1roOtz8Xxh5sFifyDo7oTyfw8VaUF4/uP5RACqtQS7j4S1RgDvbNuzpwS9Xw+LxnD8m UFrPRI0jt923Dvg0g03Gp1vncH4kwYeHI9oTj9NkVGYKMTjXR/qjY49SaiO4RmLH+0jG dgNg==
X-Gm-Message-State: AOAM533XYPLRcvd0Mt6MGTzdUaWGbwx7Nd6lHPqAqPJyDGl+PWDAYYWl zIp6s/UzBM1RvU+6nOxKD6WA7/LWdwUr7Tq275c=
X-Google-Smtp-Source: ABdhPJz7HmE/dOuEJvtV8ymXWBmADEdYlhDo6bIfRXfVXAaKMFwlGS4rPiK4o/DcZOO6Ok3r51HEgwAmrj+Pctzhj8I=
X-Received: by 2002:a25:ab6e:: with SMTP id u101mr39431047ybi.522.1625759937324; Thu, 08 Jul 2021 08:58:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Thu, 08 Jul 2021 11:58:46 -0400
Message-ID: <>
To: Ben Laurie <>
Content-Type: multipart/alternative; boundary="0000000000008dece105c69ebb29"
Archived-At: <>
Subject: Re: [CFRG] Threshold Sig required - Random bit flip hits Cert Transparency Log
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jul 2021 15:59:03 -0000

On Thu, Jul 8, 2021 at 6:37 AM Ben Laurie <> wrote:

> On Wed, 7 Jul 2021 at 17:04, Phillip Hallam-Baker <>
> wrote:
>> So it has actually happened, a one in a billion computing error has
>> caused a cert transparency log to become corrupted due to a bit flip error.
>> There is a discussion of the issue here:
>> Single random bit flip causes error in certificate transparency log |
>> Hacker News (
>> <>
>> The solution they obsess over (ECC RAM) is actually irrelevant to the
>> error in that case as it was an even rarer CPU error. Which means that what
>> I considered to be a more or less theoretical concern about signing append
>> only logs turns out to have actually occurred. Do things billions of times
>> and billion to one chances will happen.
>> The only robust solution to this issue is for redundant notaries to sign
>> the log.
> That's not true - the solution CT uses already is to have multiple
> redundant logs.

It depends on the use that you want to make of them and who is observing.
In the case of CT, this error was caught because people are continually
monitoring the logs and independently verifying integrity. Which is fine
for the specific application for CT.

The use case I am considering is how to use a chained notary approach to
notarize digital evidence.

I understand the point about attribution. As a general matter, I reject the
notion of threshold signatures where the keys are held by independent
parties as the crypto currency folk are trying to do. If Alice and Bob and
Carol are going to sign a document, the only correct tool to use is a
multi-signature, that is sign under A, B and C. Sure, we can develop a
pretty algorithm that does this, but when we embed it in a protocol...
crypto-currencies are fragile enough when exposed to the real world as it

The only use case I am interested in is when Alice is the signer and she
has redundant devices, all of which is trusted but one or more of which
might be faulty and/or compromised. In this case, I don't want to expose
the structure of how the signature came to be. So attribution doesn't
arise, if a fault occurs, Alice will be the only person who sees it.

Oh and yes, I get that it is a bit more complex and not the only way to do
this. But it is the most elegant way to do it and for some circumstances,
the additional cost is a feature, not a bug.

If I am visiting a national lab to discuss deployment of an apex notary for
the court system, they are going to be wanting to see bright shiny HSMs and
Tier 6 security etc. etc. they are going to want to perform management as
ceremonies because that is the way crypto has always been done at that
level. It is not how people administer individual machines but that is how
core crypto is managed.