Re: [Cfrg] Threshold signatures

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

So I am currently deep into the literature and trying to understand quite
where people are coming from.

There seems to be a lot of conflation of 'we can't prove this is secure'
with 'this is insecure'.

Sure, if you allow people to 'bring your own key', you are going to have to
validate those keys in some fashion before you begin. But that isn't a
signature round, it is part of the certification and/or key distribution
protocol and so it does not count against my digital signature scheme
rounds.

The path to success in academia is to invent problems that don't need
solving that have cute proofs. Yes, been there, done that. Tony Hoare was
my College Tutor. It is important to make sure that the security and
protocol properties we are validating for are in fact part of our real
requirements. I spent months reading about attempts to create 'proper'
proxy re-encryption schemes until I realized that I could avoid all the
complexity by giving people the decryption keypair rather than using one
they already had.

The field spent 20 years thinking RSA was superior to DH because DH doesn't
do 'true' public key encryption. But embedded in a protocol, DH provides
exactly the same capability as RSA - establishing a shared session key. And
it is far more flexible and does so with far less complexity. DH is
actually the better scheme but it took us too long to realize that.

So the security concerns I recognize are:

1) Engaging in the protocol causes disclosure of a participants private
signature key.

2) Engaging in the protocol to sign document M, provides an attacker with
information that allows them to sign document M' without the participation
of the full signature quorum.


Security concerns that aren't (much of) a concern to me are:

1) Introducing spurious information into the protocol causes the creation
of a signature that fails validation.

It is probably sensible for the coordinator to verify that the signature
validates. If it is possible to construct a rogue key that results in a
valid signature, then our base signature scheme is broken. But this
particular attack is irrelevant for most of the scenarios I am considering
because the key shares are split from a master key and distributed to the
key share holders in two of the three schemes. And I can use either
threshold key generation or a proof of possession mechanism in the third.

The only information the signers provide in the protocol I am currently
considering is R_i in the first round and S_i = r_i + s_i.k in the second.
Presenting a false R_i in the first round will cause the signature protocol
to fail.


As for how long it takes for the industry to get a clue, that should not be
of any concern in IRTF. I am quite happy sitting in a House or Senate
hearing telling the members of Congress that we do have the technology to
win the cryptowars but it isn't being used. I don't (often) get to talk to
current NSA directors but I do get to talk to past directors and it seems
that one of those may have started the chain reaction that caused NIST to
start looking at threshold (pity they didn't invite me to the party last
year but that is the cost of Chatham House rules).

The reason NSA was vulnerable to the Snowden breach was that the Microsoft
CRM system they were using was not designed to protect against an insider
threat. I doubt that I am the only person who has pointed out that
employing threshold decryption would allow the existing system to afford
the necessary separation of duties.

The industry does move very slowly, but one of the main reasons for that is
that there are very few people in the industry pushing to do stuff that is
breaking the established pattern because most folk are resigned to failure.
If people are resigned to failure let them say so and get out of the way of
those of us who are not. We have work to do.


On Thu, Jan 2, 2020 at 2:57 PM Tony Arcieri <[e-mail]> wrote:

> I'd be interested in comparing / contrasting your scheme to prior art with
> running code, notably:
>
> - KZen's Multiparty EdDSA, a straightforward application of distributed
> threshold Schnorr to Ed25519:
> https://github.com/KZen-networks/multi-party-eddsa
> - CoSi, a Merkle-tree based approach for collective Ed25519 signing
> targeting something more along the lines of a consensus protocol:
> https://tools.ietf.org/id/draft-ford-cfrg-cosi-00.html
>
> On Thu, Jan 2, 2020 at 2:28 PM Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>> OK so with quite a bit of help, have got a prototype of threshold
>> signatures going. There is a bit more to the draft than just the algorithm
>> though as the way the scheme is presented and packaged has consequences.
>>
>> From the presentation side, I want to be able to argue that the threshold
>> sig scheme has (almost) precisely the same security properties as the
>> RFC8032 scheme. Which means that the core of the presentation must align as
>> closely as possible with the RFC8032 scheme.
>>
>> There are some subtle design choices that don't impact security but may
>> well have impact on specific use cases. The use cases I am currently
>> considering are
>>
>> 1) HSM module: One or both parts of the signature key shares are located
>> in a HSM providing resistance against extraction of the public key. This is
>> an important use case as we want the operation of the HSM to be stateless.
>> The signing algorithm requires multiple rounds, in the first round, the
>> signer commits to a value R_i = r_i..B. In the second round, the value r_i
>> is used. So it is kinda important to construct r_i in such fashion that the
>> HSM can restore it from one round to the next even though it may have
>> performed other operations in the meantime.
>>
>> Another issue that comes up with HSMs is auditability. The construction
>> of r_i must be auditalble which means it must be deterministic.
>>
>> 2) Code signing: The code signing role is split across two or more
>> signers and MAY permit a signature to be created by a quorum smaller than
>> the total number of authorized signers (n, t). Signing quorums may prove
>> particularly attractive for open source projects.
>>
>> I have introduced a new role, of coordinator for the party that manages
>> the process.
>>
>> Are there additional use cases that should be considered. That is use
>> cases that raise additional requirements. The need to sign blockchains is
>> often raised but that doesn't seem to raise additional requirements over
>> code signing.
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>
> --
> Tony Arcieri
>