distributed secret key

Sun May 24 20:16:55 UTC 2020

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

Hi Phillip,

On Sun, 24 May 2020, Phillip Hallam-Baker wrote:

> 
> In short, yes, I have stuff that works for this and I think it would be
> particularly useful for code signing and for inside CAs. But it does need
> some additional work to apply it to that application.

this sounds promising. :-)

> 
> 
> 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?

> 
> 2) A group of people who each have a secret to jointly create a composite
> key with n shares and a threshold of n[*].

Is this a typo or is here really t=n? I'm asking, because we're actually 
more concerned about redundancy (t<n) than about the distributing (t>1) - 
though we do prefer a distributed key (e.g. t>1), if that is feasible.

> 
> These are currently specified for Ed448 or Ed25519 but conversion to the
> NIST curves is straightforward 

This might be a stupid question, but: Are there any restrictions imposed, 
what algorithms are allowed to be used by a (root) CA? Or is this mainly a 
matter of "taste"?

> 
> I do not currently have a version that supports t people coming together
> with a set of Shamir secret parameters and jointly creating n Shamir secret
> parameters. There is a proposal (FROST) to do that but the authors are not
> ready for it to be used.

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).

> 
> 
> [*] The particular concern here is that it is necessary to defeat a
> malicious contribution attack in which Alice Bob and Mallet jointly create a
> key but Mallet goes last and instead of contributing to the shared secret,
> he instead generates a new key pair and calculates the public value that
> will trick Alice and Bob into accepting his as the valid one. Whether this
> attack is relevant or not depends on your intended protocol. 
> 
> For example, lets say Alice and Bob's key pairs are {a.P, a}, {b.P, b}.
> Mallet is supposed to contribute m.P from {m.P, m} and the composite key
> will be {x.P, x} where x = a+b+m.
> 
> Instead Mallet contributes (z-a-b).P which he can calculate by generating z
> and calculating z.P-a.P-B.P so the composite key x = a+b+m = a+b+z-a-b = z.
> So Mallet knows the secret key and only Mallet can use it.
> 
> 
> 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?

> 
> 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.

Regards,
Erich

> 
> 
> On Sun, May 24, 2020 at 12:20 PM Michael Richardson <mcr at sandelman.ca>
> wrote:
>
>       Erich Eckner <openssl at eckner.net> wrote:
>           > we're looking into setting up a CA with openssl, but we
>       would like to
>           > distribute the secret key amongst multiple persons. We're
>       aware of
>           > Shamir's secret sharing algorithm, but we'd like to know
>       if there is some
>           > algorithm supported by openssl, that fulfills the
>       following requirements
>           > (2 and 3 are not fulfilled by Shamir's algorithm):
>
>           > 1. Secret key shared amongst N persons, M<N shares
>       sufficient for using
>           > the key.
>
>           > 2. No secret material (or parts thereof) needs to be sent
>       around,
>           > preferably not even during creation of the key.
>
>       So you want to split a secret, but then not send anything to
>       anyone?
>       I don't really understand this at all.  I don't think it's
>       physically
>       possible.  Maybe you could restate your requirement in another
>       way.
>
>           > 3. Secret key will not be assembled from the shares for
>       the acutal
>           > operation. E.g. each share operates independently, and the
>       intermediate
>           > result is sent around, after M keyparts operated on it,
>       the signature is
>           > complete and can be used.
>
>       I guess you want a system where the shares can be added after
>       "exponentiation" rather than before.
>
>           > If this is not supported by openssl, we're also open for
>       suggestions of
>           > other (open source, free-to-use) software, that can
>       achieve this and
>           > creates standard X.509 certificates (not sure if I termed
>       that correctly).
>
>       I believe that Phillip Hallam-Baker's
>                          Threshold Modes in Elliptic Curves
>                            draft-hallambaker-threshold-02
>
>       may fullfil your needs.  It might even satisfy (2), but I'm not
>       sure it
>       satisfies (1).  It may be that you don't need to satisfy (1).
>
>       I know that Phil has running code, but I don't think it's based
>       upon openssl.
>
>       --
>       ]               Never tell me the odds!                 | ipv6
>       mesh networks [
>       ]   Michael Richardson, Sandelman Software Works        |    IoT
>       architect   [
>       ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby
>       on rails    [
> 
> 
> 
> --
> Website: http://hallambaker.com/
> 
>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7K1jkACgkQCu7JB1Xa
e1qTFw//fpz+GzA9C/JZ14LjNuhbi6mVtGwUAxEugFuStpeMASIgqtXT2Lje7o+Z
RUAliQ3UGaOllK0yssmv73SA3ZCs/Wm4CZ+bdIsLxkKDxpJOv80sM8A6dS62/nBK
zaqftxj9Aj7DUa9mZ4Vu4JdGwdNADU0czHRxbVH1ljsJYFdTYNdTnEuOk5vO5u+5
5JDcd/dxisav/Ivv1mw101UQyrQZ0lR9TZXgdOPw8sanViSEjAp/lJM7jutjH8Rm
mWqtIvds+DS50u1mh/Y/fG3Q7tVNrqOoT2m6heY2l1Ve4gVpfQYiIEFNQqaQ9zF2
OKWuiwmq7Drc5vuiIEuIjMER2VhbFdSqsJmPWyQgmnXiNDLxFIYirs1+7bb5yCbE
OwGPqTS8goCPVRMwyhxnHQkxvD42uz9L6A1cxhVnZEy1RSfnMIC+ttVKsMTbifzv
YVo8tNoEraQfXdu07d/ulJscKZHhFp6z5nP7rm3OIUyGObZJQyaiAnHRtYqI4KL5
ZhGh9X0gFXl04ZF63ypc5F54WL8qEAuxm8rJpVO4XbSoaX9AwEnNoP400fajYUwI
UmO78qLyXSdHvMEfFdLAZubmcP3jeG5TL+ffTmJUJw60glnkb4JtOnoBNopGm8ej
N4FbncsltkGfG8W58rEqkLz+Y4dxF9RrsE+WzBBg0YR9wX9Bkg8=
=ntAn
-----END PGP SIGNATURE-----