| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updated many dependencies, notably secret-sharing which dropped the dep on
polynomial, and so allows building with ghc 8.x.
Did not try to support building with older ghc because the semigroup-monid
transition would make it nontrivial.
Stackage lts-14.25 is a compromise, since the stack shipped in debian (even
unstable) is not able to handle newer ones.
This commit was sponsored by Eric Drechsel on Patreon.
|
|
|
|
|
|
|
|
| |
* New --add-storage-directory and --add-server options, which can be used
to make keysafe backup/restore using additional locations.
* Removed --store-local option; use --add-storage-directory instead.
This commit was sponsored by Thomas Hochstein on Patreon.
|
|
|
|
|
|
|
| |
This allows local storage locations to have levels too, and also get
shuffled nicely.
This commit was sponsored by Ethan Aubin.
|
|
|
|
|
|
| |
what servers keysafe knows about, and as a cron job.
This commit was sponsored by Jake Vosloo on Patreon.
|
|
|
|
|
|
|
| |
May help avoid some correlations. Once there are many servers, will spread
the load out amoung them.
This commit was sponsored by Ethan Aubin.
|
|
|
|
| |
This commit was sponsored by Jeff Goeke-Smith on Patreon.
|
| |
|
|
|
|
|
|
|
| |
This will prevent --autostart from prompting to get the newly restored key
backed up again.
This commit was sponsored by Remy van Elst on Patreon.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the server list to contain 3 servers although only 1 is running
so far; uploads to the others will be queued.
It also allows a server to be spread amoung multiple addresses, which may
be useful later for scaling.
This changes BackupRecord serialization, but it's not been in a keysafe
release yet, so that's not a problem.
This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
|
|
|
|
|
|
|
|
| |
of work.
This got out of whack when sections were converted to rationals; there were
buckets that needed trivial proofs of work, and having these extra buckets
increased the total possible throughput.
|
|
|
|
|
|
|
|
| |
This can be deleted by the user at any time, but it's useful in case a
server is known to be compromised, or a problem is found with keysafe's
implementation that makes a backup insecure.
This commit was sponsored by Nick Daly on Patreon.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The server has to run the hash once to verify a request, so a hash that
took 4 seconds could make the server do too much work if it's being flooded
with requests.
So, made the hash much less expensive.
This required keeping track of fractional seconds. Actually, I used
Rational for them, to avoid most rounding problems. That turned out nice.
I've only tuned the proofOfWorkHashTunable on my fanless overheating
laptop so far. It seems to be fairly reasonablly tuned though.
|
| |
|
|
|
|
|
| |
This only affects time estimates while keysafe is generating hashes;
it does not affect cost estimates to brute-force.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This makes it clearer that it's not a chunk of data, but a Shamir share.
|
|
|
|
|
|
|
|
|
|
|
| |
There needs to be a 1:1 mapping between upload queues and servers,
otherwise using the upload queue risks two shards for the same object
being uploaded to the same server.
Also, fixed storeShards to give up on StoreAlreadyExists, rather than
trying another storage location. Otherwise, on a name collision,
the shards would be rejected by the servers, and be stored to their upload
queues.
|
|
|
|
| |
also, server upload queues in ~/.keysafe
|
| |
|
| |
|
| |
|
|
|
|
| |
also, restore actually works!
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This should be good enough to let the keysafe UI comment on
how good a password the user chooses.
|
| |
|
|
|
|
|
| |
Needed for efficient serialization of shares, unless upstream takes my
suggestion to make the finite field be size 256.
|
| |
|
| |
|
|
|