Secret Sharing

Bernd Eckenfels lists at lina.inka.de
Wed Mar 26 05:03:23 CET 2008


On Thu, Mar 20, 2008 at 08:04:38PM +0100, Phil Sutter wrote:
> Well, this is exactly the problem I'm currently working on. Security
> indeed is a big problem here, as in fact secret data has to be exchanged
> somehow, and in many cases this allows bad people to collect shares
> until they are able to recreate the secret themselves. On the other hand
> GnuPG until now is just an application without daemon-functionality. I
> doubt it's economic to change this.

The question is, what secrets are we talking about. I can imagine first of
all, u plan a secret sharing where you simply "mix" user entry
passphrases for the symmetric security (i.e. for encrypting files or keys).

If we are talking about secret keys, the infrastructure (like a TCB booting
from a self verifying media) is usually needed anyway. So it might not be
needed to change Gnupg itself at all, you could just construct the secret
key in a ram disk in such a secured device.

(I am not sure if you plan to have a method, where you actually modify the
actual algorithms to work with additional secrets. This would have the
advantage that you never reconstruct the secret - but I am not sure if that
is possible for RSA, DSA - possibly for ECC. So if we define that
reconstructing the key is needed, a lot of that can be done outside the
gnupg binary. Maybe you can even write a new daemon for the crypto card
provider interface of gnupg.)

> Yes, I will do that as soon as I made up some methods of handling the
> actions involved in secret sharing. I've already thought about using
> existing GnuPG features for establishing secured connections, e.g. via
> encrypted emails. But the implementations of this kind of delayed
> communication still have to be evaluated.

Ah this sounds like you just want to have a GnuPG Encryption/Decryption mode
which can be used by multiple users to work on Data. In that case the
question is, if you want to exchnage the packet format to add new blocks for
holding data which allows partial revealing of the session keys.

Gruss
Bernd



More information about the Gnupg-devel mailing list