-----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@xxxxxxxxxx> 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-----
