[sugar] Disconnected backups.

Jameson "Chema" Quinn jquinn
Thu Feb 21 18:35:17 EST 2008

I don't know what you mean by "erasure-coded". I am only talking about
storing something the size of a private key - say, 2K - on three other
laptops. Your own private key would be 2K and you would, on average, have 3
other keys - a grand total of 8K average. Not going to break the back of
even the most limited modern storage.

But considering the complexity of implementing key-part-management (mostly
on the restore side of the equation), I think that brute-forceable password
encryption of the backed-up private key is the better idea. The automated
brute-forcing script should be written for the XO, not for the server
(although of course porting it would be easy). When creating your password,
it should even give you a pregenerated default random password.

If you just broke your XO and forgot (or never wrote down) your password, a
few more hours of cracking once you get your new XO is a minor nuisance. And
yet this simple step would cut down privacy invasions by orders of
magnitude, IMO.

On Tue, Feb 19, 2008 at 2:36 PM, Ivan Krsti? <
krstic at solarsail.hcs.harvard.edu> wrote:

> On Feb 19, 2008, at 3:32 PM, Jameson Chema Quinn wrote:
> > That's a separate issue - at the simplest, you just store the
> > encryption key on the first backup and only manually thereafter; a
> > more complicated scheme, for implementing later, would break it into
> > 5 parts of which any 3 would suffice, and store the same 2 parts on
> > all the backups
> Collaborative erasure-coded backups are not a good idea for devices
> with very limited storage, except in special cases.
> --
> Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080221/5be49a42/attachment.htm 

More information about the Sugar-devel mailing list