| Subject: | Validate (and document) that brackup provides "naked-grade" backup capability |
OK, the previous bugs cover the more obvious things, now onto more
general features you may or may not want.
"Naked Security" is a term I like to use for a security system that work
(lets you in, keeps others out) even in the worst possible case, where
someone pull you out of the ocean naked, and dumps you at your house
without keys or anything. This could be something as simple as hiding a
key somewhere truly obscure, or biometrics etc etc.
"Naked Backups" would probably be more important. Imagine you work from
home on the coast of say Florida, and your town gets hit by tsunami or
some other massive disaster (think indonesia). You get dragged
unconcious from the raging floodwaters naked. Your flash key is gone,
your laptop is gone, your computers, house, office, servers, everything.
All gone.
That's what things like Amazon S3 are made for, so even in majorly bad
situations, you can recover.
Whatever the crypto you use, whatever the way you index or transfer or
backup, you should be able to have a way to organise your backups so
that even in the worse possible situations, you can still get them.
If your access to the backup system is reliant on symmetrical crypto,
and your private keys get washed away or blown up, or otherwise
destroyed, is your backup actually safe? If the data is all there, but
you can't access it because you lost the private keys, then you might as
well have lost the data as well.
That would be bad.
So while I'm still working out how you are doing crypto, you should
certainly make sure that losing the private key doesn't mean losing the
data.
And if brackup meets this benchmark, or has a rule like "under no
situation EVER lose your private key, or you've lost your data" make
sure this is VERY VERY well documented.