Discuss mailing list

[Erich Eckner <opennic AT eckner.net>]

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

On Sun, 24 May 2020, Rouben wrote:

> Hi Erich et al,

Hi Rob,

I'll answer inline (as I usually do).

> My apologies in advance for a wall of text. I also want to repeat that I am
> in no way a crypto expert, and don't claim to fully understand any of the
> above, especially the algorithms/math/cryptography behind it, just the
> high-level concepts and "advanced end-user" level implementation thereof.
>
> First, I was referring to a distributed WoT model by monkeysphere. Their
> browser extension approach is intriguing and could work for us... the only
> issue is, browser extensions, especially those that rely on "native
> messaging hosts" (extra software that needs to be set up in order to
> interact with the end-user's OS), are a pain in the ass to install. It's
> more painful than simply installing a CA cert, I think, unless we wrap the
> browser extension into a super easy installer for each major platform.

I find a browser extension sub-optimal and certificates which only work 
with a browser extension insufficient: There are many other ways to 
interact with the web besides "a browser". For example, I need ssl 
certificates which can be natively validated by my linux package manager, 
curl and openssl itself. Also I doubt, that browser extensions cover all 
the range of strange browsers (old internet explorers, text-only browsers, 
...)

> Second, I was referring to Blakely-Shamir secret sharing that was available
> in the commercial and freeware versions of PGP, but doesn't seem to be
> available in GnuPG (GPG) and Open/LibreSSL. Here's the relevantdocumentation: 
> https://knowledge.broadcom.com/external/article?legacyId=HOW
> TO42097
>
> Note, this is not the same as "shared secret", i.e. just copying the private
> key and sending its copies to each person. More
> info https://en.wikipedia.org/wiki/Secret_sharing

Yes, I'm aware of that algorithm (basically, it is similar to RAID). My 
concern was, that it required the creation of a (combined) secret key, 
which *then* gets splitted. But I guess, I'm asking for too much (in terms 
of what is already implemented in software, not what is possible 
theoretically), if I want that there was never the secret key existent, 
only parts thereof.

> PGP (the commercial software) did this neatly. In a nutshell this feature
> allowed to split a PGP private key into N parts, each with its own
> individual owner and owner's unique passphrase. In order to conduct any kind
> of crypto operations with this split key (decryption and signing), M out of
> N owners needed to perform it, where M < N. The way it was implemented was
> cool too; each owner of a split key piece could perform the operation
> asynchronously and on their own, and pass on the intermediate output of the
> operation to the group. Once a sufficient number of owners (i.e. M)
> performed the operation, the final output (e.g. decrypted text, or signed
> data/cert) was generated. For example:
>
> ACME Inc has 3 employees (N=3), Bob, Alice and Joe. They create a "split"
> secret key and each has their own share of the key with its own unique
> passphrase. They decide on a 2 out of 3 key sharing policy (M=2), where any
> 2 of them are required to perform secret key operations. The public key is
> not split, and available on ACME's company website.
>
> Carl, a customer of ACME, uses the public key on the company's website to
> encrypt a sensitive document and sends it to ACME's public mailbox.
>
> Bob gets Carl's encrypted email, and uses his share of the secret key to
> produce an intermediate called Bob1. Bob then passes on Bob1 to Alice.
> Alice's email is set to autoreply that she's on vacation until next week.
> Bob then passes Bob1 to Joe. Joe, receives Bob1 and decrypts it with his
> share of the shared secret key. Since 2 shares of the keys were used, Joe
> obtains the fully decrypted document sent by Carl. Joe then shares Carl's
> decrypted document with the group.

Yes, in order for us to meaningfully use this split-key scheme, there 
would be some support needed from the software (I'll ask on the 
openssl-users mailing list, if openssl supports something like this) - it 
would make no sense for us to glue the private key together somewhere to 
extend the validity of the intermediate ca certificates ...

> Here's a "democratic CA" example:
> Suppose OpenNIC has 3 elected "cert signers" and a policy where 2 out of 3
> of them need to agree to sign the cert. You see where I am going with this?

yes, this sounds loveley.

> Just replay the Carl, Alice, Bob and Joe example above replacing
> Carl's document with Carl's intermediate CA cert signing request (CSR) and
> "decryption" with "signing", and the ACME Inc corporate key with the root CA
> cert private key. This could be used to allow a group of people to "vote"
> whether or not to sign a candidate's (Carl's) CA cert with the root CA
> cert's private key. And yes, you could do this in PGP (not GPG, AFAIK) out
> of the box to allow an organization to split the responsibility of PGP key
> owner identity verification among a group of people.
>
> They key features here were that:
> 1. Any secret (including private/secret key) can be split into a N of M type
> scenario. This can be achieved with the Shamir/Blakely secret sharing
> algorithm. An open source implementation of this is called gfshare, and is
> available as a DEB package on Ubuntu.
> 2. IMPORTANT: the shares can be used by different people on different
> machines at different times to produce intermediate data (encrypted?) that
> can be securely passed around to the individual secret key share holders, so
> they can use their key shares/parts independently at a time/place convenient
> for them.
> 3. Once the sufficient number of shareholders used their shares of the
> shared secret key, the message is fully decrypted.
> 4. Presumably none of the shareholders were able to reconstruct the original
> "split" secret key, i.e. Joe was not able to reconstruct and captire the
> full secret key from Bob's intermediate message Bob1.
>
> The problem here is that the gfshare implementation won't work, because it
> can't be used to produce an intermediate output ("partially encrypted") that
> can be passed on to the remaining shareholders. This *was* possible with
> PGP. AFAIK neither GPG (GNU Privacy Guard) not Open/LibreSSL offer this out
> of the box. I'm not sure why, because I think in a CA scenario, the root
> cert's private key could be "protected" this way.
>
> The man page ofgfshare 
> http://manpages.ubuntu.com/manpages/focal/en/man7/gfshare.7.html do
> es offer an interesting scenario that can be used to back up a master GPG
> private key used to certify its subkeys. Basically the idea is that when you
> create a GPG key, you have one master key that's only allowed to certify
> (i.e. edit the key, such as add/edit/remove subkeys, extend validity, etc),
> and you also have 3 separate subkeys that are used exclusively for signing,
> encryption/decryption and authentication. This is described in detail
> here: https://github.com/drduh/YubiKey-Guide in conjunction to using a
> hardware token, like a YubiKey, to store all the subkeys. The "master" key
> is stored offline, and is never used on a machine that goes online. In a
> sense, the "master" key is like the CA Key of your GPG key, while the
> signing, encryption and auth keys are like the certs you use for specific
> functions. In theory, instead of storing your master key in cold storage,
> you could use gfshare to split it up between N places, and securely store
> each shard in different places. You'd need a certain number of these shards
> to reconstruct the master key in order to edit your GPG keypair (eg. do this
> every year to extend its validity). You could also do the same with the
> revocation certificate for your key and use the same method to reconstruct
> it if your GPG key ever gets compromised.
>
> In case of personal GPG keys, I understand the above is quite "cypherpunk"
> level hardcore, but hey, it's nice to know it's possible. In the context of
> a CA, I think it's quite useful... but alas, I lack the skills/understanding
> here to be of any further help/use.

The problem I see with this is, that each time you want to do something 
with your key (e.g. sign the intermediate ca), someone must assemble it 
from the shards. This requires us to send (parts of) private key material 
around, which is undesirable. Additionally, you must put extra-trust into 
that someone, that he will delete the reconstructed private key properly 
after signing (and only signing what consent was reached, etc.).

If it turns out to be impossible to have a distributed secret key which 
does not need to be sent around in order to actually sign something, I'm 
in favour of having multiple root CAs for now (to increase the bus factor) 
and trust, that the owners of those CAs handle it properly and only sign 
what the community has consent about.

> Rouben

regards,
Erich

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

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KQXEACgkQCu7JB1Xa
e1rmnhAAh+N5gDXJ+7MfjP/iBr7ww1Itww6zgwImP1HH9iPs93HBOOlvzZsOK1c8
emB9lzWMkEwOcS3hhwRGwC10iDI2Pd5KVaS3wCJGRyMIyKPbnI1C0gXY9SBSAfHX
khcWKJTTs1mYJGFMkamNO4X/1JBg8mrXOPu8nLq79NTsP7roVaH/l5qvwa0ZAfxf
uoXB70A8mhK60cmKIr0jN/VUI243FTHOLPNtqEgT6Urh+Qt/rK+rsLYcU7/cNvHy
FFc+CHMq9DIkCeFpNxsJfCdsizv+JohBJwMy1UVO+qluZ9yk4I8BC66g87ghhxCe
ocwcyiPQ5NvSOvZZlBEtgkpE3Nkkr6Sd2KuZiMJeuwxomSlpcK4PdoRZ6TeqddAy
E3p+abWmHlZFBneyd1/v788O3WkxhA50UgOE6xtlDTidDHywviyzmsAWskZwF8HF
I7xKTV8sYdSdA9m+tYTh9s4sL+NYwXz7MDSdSqmN2mWkZT43/9bYF64a8nN37NTW
atOI5yEBu/UoWHc0GfEzS4TMSlaZf7T+smYuz1LSHNRNYsWeknM7DTs+uq4OC5W2
CDin339um6/Ce0YvA+tS9pAG2jvetaWN9QQZiuhq6b+528msiOffiBi0GoPPSgZz
ZvcyDapChIFal23pSLzQ3uipvDcS0s3+lVAWTyRuVsEa+RQD21U=
=JR/j
-----END PGP SIGNATURE-----