Policy-Discussion

[Faramir <faramir.cl AT gmail.com>]

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

Tomáš Trnka escribió:
...
> (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).

  There is a windows port of the code, but it is outdated, and if I
understood it right, there may be problems with the source of entropy.
Maybe, in the case the SSSS approach is accepted, you can contact the
author to discuss it, or maybe people of GnuPG can provide a hint for
porting crypto stuff from linux to windows... the home site of the
windows port is http://www.seidlitz.ca/ssss/

...
>>   I suppose the biggest risk would be if SSSS would become unavailable...
> What do you mean by "SSSS becoming unavailable"?

  Well, if nobody maintains the package, there may come a day, let's
say, in 10 years, when the package won't run in current versions of
ubuntu or windows, and also, previous versions of ubuntu or windows
maybe won't run on the existing hardware. However, maybe there will be
emulators...

...
>>> 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.

  Right, but also, if we change the "trustees" on yearly basis, maybe we
would need to change the envelope on yearly basis? (changing the
passphrase, and generating new shares). But that problem can happen with
the current envelope too, since, right now, Teus has an envelope, and he
is not currently the president of CAcert Inc. And soon there will be the
AGM, and maybe all the board will change.

  I have not read much about key escrow, but what I have read, make it
looks like a complex problem to solve :(


>>   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).

  Right, but it still provides a simple way to store the
must-not-be-lost files... I mean, maybe it would be easier to contact
Teus and ask him to return the envelope, than contacting 7 former board
members. But relying on the availability of a single person/enterprise
for keeping the envelope safe makes it easier to become unavailable too.
 What if the notary dies and his heirs just shut down the business? I
don't know how do these things work.

  I have a small story: the school I studied in, had some founds
invested with a former student. They trusted him, and everything went
right, until the person unexpectedly died. Nobody could find records
about where was the money, it seems the info was only in the head of the
person in charge. The school almost went to bankruptcy, I don't know how
they managed to solve the problem, but afaik, the money was never recovered.

...
>>   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.

  Yes, I don't like too much the idea of relying in online tools,
specially for emergency recovery events. But since my programming skills
are not enough to even understand how SSSS works, I was trying to find a
way to avoid having to port the software to different plataforms.

  By the way, if we use that software, we don't need everybody having
access to SSSS, 7 persons may be required to provide their shares, but
only one machine is required to recover the secret.


>>>>    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?

  AFAIK, it should be...

  Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJLS6aGAAoJEMV4f6PvczxAQhAIAK4tSLQ4355SEZKXeeM/nbTT
ujsrE4S4jkMZrJ6K1M2nSo/hszcuCmJ60HZIbkQbIL4EIHR+Kay8KnccirQ7p1uu
Qoj7DmM3LoG5XgRQVRmGmLZhEida24suC0KWMkgbyYynqwG1xqEciNzbLknCrEO2
MR4WpZFFAn4KwDTybe0B6MCOdPsyXDGtgXQojH7kfO1FF2pV3rM2nd//yd4jtCpi
sAs79mSNPGBpQwLo8jnQRvxQ5X8B7ld8lW62/yEeLfewirhUXvP4NDIZEU2RB55J
PuE+RaLBO49B6AQ/4XOAf/OrNJQ4pWiI03D6B9dVocFyjK8dgxFcygioXSAskXE=
=AmtH
-----END PGP SIGNATURE-----