-----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@xxxxxxxxxxxx>
wrote:
Erich Eckner <openssl@xxxxxxxxxx> 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@xxxxxxxxxxxx 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-----
