distributed secret key

Wed Jun 3 09:26:05 UTC 2020

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Phillip,

@all: If this goes too far off-topic for the openssl mailing list, let me 
know, and I'll continue the discussion off-mailing-list.

On Mon, 25 May 2020, Phillip Hallam-Baker wrote:

> 
> 
> On Sun, May 24, 2020 at 4:17 PM Erich Eckner <openssl at eckner.net> wrote:
>
>       On Sun, 24 May 2020, Phillip Hallam-Baker wrote:
>
>       >
>       > I do indeed have running code but not (necessarily) for this
>       particular
>       > variant (yet).
>       >
>       > What I have right now is a scheme that allows
>       >
>       > 1)  An existing secret key to be split into (n,t) shares where
>       the threshold
>       > t < number of shares.
>
>       I suppose, this includes also the part to use/reconstruct the
>       secret key?
>       May I ask, what we need to do to sign something with the
>       splitted key?
> 
> 
> It is all explained in the draft but basically for the n=t version, you have
> a minimum of two rounds. In round 1, everyone has to agree on their secret
> key blinding value k_i and make a commitment to R_i = k_i.P. Then the dealer
> has to gather up the commitments to calculate the value R as their sum -
> from which the message digest value can be calculated. Then each signer just
> signs as normal.
> 
> It is all very straightforward. Very little has to change.
> 
> To do n<t then you have to calculate the lagrange coefficient and multiply
> your secret key by that factor. Again explained in the draft.
>

Sry, I missed that before. I have just read the draft, now.

>  
> 
> Nope, I haven't got a fully finished scheme for the Shamir Secret Sharing
> t<n version (yet) that begins with a distributed key generation scheme. 

ok, I see.

> 
> In fact, I have yet to fully grock how that starts. Do we have n people
> participate or t? I can carry the math part. But there seems to be this gap
> when I try to move to ceremony...

Well, there is only t parts of information in there (e.g. if t parties 
would share their secrets, the other n-t secrets could be reconstructed). 
So one way would be to have t parties "settle on a shared key" and 
calculate the n-t other secrets - but this creates some asymmetry between 
the trust in the parties. Maybe it's instead possible to have n parties 
create secrets, and then "project" this n-dimensional key onto some 
t-dimensional hyperplane without actually sending the secrets around? 
(This might work with the "n points of a polinomial of degree t-1" 
approach, too: "projecting" would refer to some kind of fitting, there)

So everyone would do:
1. create some secret
2. send some information around
3. calculate the component of "his coordinate" of the perpendicular to the 
t-dimensional hyperplane
4. subtract that from his secret

> 
> 
> What are you hoping to use this CA for? It it is to issue WebPKI (i.e. get
> your root embedded in a browser) certs then CABForum writes the rules. They
> have picked a set of algorithms/ curves they like. 

Yes, it should become the root CA for OpenNIC to certify webservers. At 
some point (very long shot), it might get included in browers, but I 
honestly do not expect this to happen within the next decade ;-) 
Nevertheless, we would like to avoid any trivially-avoidable obstacles and 
create a CA that is as much conformant to the rules as possible :-)

> 
> But you have to use HSMs and that is a bigger constraint and none of that
> supports threshold - or is likely to for some time.

Hmm, I was afraid, we would need HSMs, too. Your draft mentions, that one 
of the participants could be an HSM - but I guess, this a) is not (yet) 
implemented and b) does not scale to more than 1 HSM because of the 
statelessness of the HSM (one would need at least n-t+1 HSMs, to satisfy 
the "have to use HSMs" condition, I guess). Am I right? If so, we will 
refrain from our bold goal of being included in browser bundles and simply 
not use HSMs.

> 
>
>       Ok, so we will probably say good bye to the
>       separately-created-key
>       approach and split a given secret key which we will afterwards
>       securely
>       erase (and only keep the parts).
> 
> 
> That is the simplest one as far as ceremony goes.
> 
>
>       > For the set of applications I care about, this attack is not
>       actually that
>       > important because while Mallet knows the secret key, he is the
>       only person
>       > who does. And so he won't be able to respond to any composite
>       signature
>       > request with a valid answer. 
>
>       But he can still sign anything he wants, right? Or does he never
>       see the
>       csr, but only the "preprocessed" csr, so he cannot sign it?
> 
> 
> Well he can sign anything he wants but why is that key accredited to
> anything else? Why is it considered to be a trustworthy key for that group
> of signers?
> 
> This is what I am trying to get at with mention of 'CSR' - there has to be
> some 'get trusted' process.
> 
>  
>       >
>       > So for PKIX type applications, this is self defeating as only
>       Mallet can
>       > generate the CSR.
>
>       Why would they want to create CSRs? In our case, this is
>       intended to be
>       the Root CA.
> 
> 
> Its been over a decade since I last stood up a production CA. It is really a
> matter of ceremony design. Having the offline root first generate a CSR and
> then accept the CSR by signing it means that the ceremony for generating the
> self signed root is the same as that for the subordinates for a start. 

Ah, I see: When creating the self-signature of the CA itself, the 
threshold signature will fail, because the keys do not fit. Although 
Mallet can create a valid self-signature, no one would use it, because 
it's clear, that this was not created by the threshold signature 
algorithm.

Can you please share some running code, that implements the t<n threshold 
signing and the key splitting (from a single key)?

regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7XbK4ACgkQCu7JB1Xa
e1qXAQ//SpsK440wb2IFd8ikTliYlnAdOLyu7LejOVAbAJv7+ZEAvMBjI3NVzRXd
RSO873ROXNeCZNLUpmktreSD6vZwnrDaingGZLTYY7JiIZ4GVORYcENXZlLmCzUg
842j8rjN7kYFoef5qqzB78BsQDmRfat5YZmroWPs2Oul9oyxZR715i0zWPFSHYkO
kFWhTg0jiYFkMyGAmgSw5d+zkxEFnwzVlTFBWKVwqvzzahBg2+NdwdI9fTg4OG2+
xEa/BjmhKSNXzpaCTRdknMvZtwENYmuqMs+78UFyYS4pjit4FDIL40uStpNvpea7
BZK+jRDIGjMvUL8Mq2YOWk57POZFsj5zil+CRkAmb639nAtj1GqBr9cCh5DVZqCt
ZihcGRxf6VKegilhvo1272BSyUlTo92ldebw5lVWLPxNuWRv2mibNuD3JXaC7TKd
FHW10iTiUHQI+Ztpl/DT3FnRLltd8w3K/uqFTI0rmdg1vqXDWLj2KCoBzXscv6Gz
/yVOqQslvMIDQCtPkP4g/nBhgYQ9/oNeeULib3VOgUFoTQeTGsi+xGavW/iEH/lG
EnSKFszucQlqHx2ylnjSXY4KVGnltCmer8KGXnKB8qXsA/uORUOAghC3ckieCeR1
bH3/w/Y35ui8952sH6ipVnh2e2FmAHeQ/lKOytg4rdjMyb0cLRk=
=Y1G5
-----END PGP SIGNATURE-----