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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Jul 8, 2021 at 6:37 AM Ben Laurie <[e-mail]> wrote:

>
>
> On Wed, 7 Jul 2021 at 17:04, Phillip Hallam-Baker <[e-mail]>
> 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 (ycombinator.com)
>> <https://news.ycombinator.com/item?id=27728287>
>>
>> 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
is...

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.