distributed secret key
Erich Eckner
openssl at eckner.net
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-----
More information about the openssl-users
mailing list