Policy-Discussion

[Tomáš Trnka <TomTrnka AT seznam.cz>]

Dne Pá 8. ledna 2010 23:58:36 Javier Fernandez napsal(a):
> Ian G escribió:
> > Hi Faramir,
> >
> > How about we take this off the board list and over to the software devel
> > list ... where there might be more interest and understanding?
> 
>   Good idea. But also, I think if we can't find a reliable tool already
> created, we should not ask our developers to create it, since they are
> already busy with other things...

(snip)

I've looked at the code from http://point-at-infinity.org/ssss/ and it's 
extremely simple (just as the underlying mathematic idea) and there should be 
little work porting it to various systems (universal static Linux binary, 
Windows, perhaps MacOS, provided I have access to some Mac machine to test 
it). Since I'm a rather experienced C programmer, I hereby volunteer to do it 
myself (in case the SSSS approach is accepted).

>    Anyway, lets imagine the following: the encrypted files are stored in
> an envelope, but instead of storing the passphrase in another envelope,
> the passphrase is split using an N of M scheme (with SSSS), and each
> member of the board receives an envelope with a piece of the passphrase.
> Even if the Notary drops the envelope to the trash can, since the
> passphrase is not included, nobody can decrypt the files. The pieces of
> the passphrase don't need to be in a digital support, they can be
> printed in paper, which is the most time-proof support media available.
> Also, it's easy to safely destroy a printed copy of the passphrase piece.

This seems like The Right Way for me.

(snip)
> > If secure means "cannot be recovered by people with n-1 shares" then OK.
> >  But note that I am suggesting a wider definition that includes the
> > overall security delivered to the community.
> 
>   I suppose the biggest risk would be if SSSS would become unavailable...
What do you mean by "SSSS becoming unavailable"?


> > Consider it to be the denial of service of cryptography.  If the system
> 
>   Right, currently I think the most pressing issue with the envelope
> procedure, is the person having the envelope can become unavailable...
> 
> >>    About reliability: if one person has one envelope, that person has
> >> full power (which may be good or not so good), but also means that
> >> person must be really careful when crossing the streets, unless there is
> >> another person with another envelope, and that second person would have
> >> full power too.
> >
> > Right.  With multiple full envelopes, the reliability of delivery of the
> > secret when needed goes right up to near 100%.  But the reliability of
> > losing the secret to someone else goes up too.
> >
> > So the trick is, can we keep the rate of good delivery up while keeping
> > the rate of bad delivery down?

I don't think we'd need to recover the secret very often, therefore we could 
easily require quite a lot of pieces to assemble it. Imagine having 10 pieces 
total and requiring 7 of them to recover the key (the numbers are just for 
illustration). It's rather improbable for 3 pieceholders to get 
lost/killed/fed up with CAcert at the same time and OTOH as soon as an 
attacker has 70% control over CAcert, there is little we should protect.

>   Yes, we can keep using that very important envelope (encrypted files
> plus passphrases), but we can also create a secondary set of envelopes
> with the encrypted files, but without the passphrase required to decrypt
> them. The passphrase would be split in an n/m scheme...

IMHO the "very important envelope" would just lower the security of the whole 
system without providing any net gain (based on my assumption that the key 
will be seldom needed).
 
(snip)

> >>    Disadvantage: while we can always open an envelope, to recover a
> >> shared secret we need the same software used to create it (different
> >> implementations of Shamir's Shared Secret Scheme work in different
> >> ways), but as long as the source code is known, it is unlikely that
> >> software would become unavailable.
> >
> > Ah.  So we need to factor in something like, our Support team must
> > support a piece of software on the various laptops of our board team. So
> > that means:  OSX, Linux, Vista, W7, ...
> 
>   I tested the web demo at http://point-at-infinity.org/ssss/demo.html
> for compatibility with the software in ubuntu, and they are
> compatible... so maybe we can implement a copy of the demo website, but
> using https instead of http, then people would be able to use the
> software without the need to have ubuntu in their machines... but I
> don't know if that would be secure enough.

I don't exactly like the idea, since that would require another super-secure 
machine to run the web app on. And taking the simplicity of the CLI app into 
account, I don't see a problem in supporting it on lots of systems.

> >>    Implementations: there is a package available for Ubuntu, and an
> >> implementation available for windows (I tested them, and shares created
> >> in windows can be restored in ubuntu, but shares created in ubuntu can't
> >> be recovered in windows. They are opensource so somebody -not me- can
> >> try to fix that compatibility issue).

I've not investigated this anyhow, but isn't the Ubuntu one the http://point-
at-infinity.org/ssss/ one?

(snip)

2T

Attachment: smime.p7s
Description: S/MIME cryptographic signature