| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there are 3 chunks each split into 3 shares and distributed amoung 9
servers, and 2 shares are needed to recover each chunk, then with AONT,
6 servers need to collude to do so. Without AONT, a single chunk might
contain the actual gpg private key, and only 3 servers might need to
collude to recover that single chunk.
On the other hand, with 9 servers, SSS can split the data into 9 shares
with 6 needed for recovery. Thus, 6 servers will be needed to recover
any data at all, no matter how it's chunked or which chunks contain the
actual gpg key.
So, I think that tuning SSS can provide the same effects as AONT.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
password.
This commit was sponsored by Ignacio on Patreon.
|
| |
|
|
|
|
|
|
| |
Hoped this will be Recommended, but it's still being vetted.
This commit was sponsored by Andreas 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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
May help avoid some correlations. Once there are many servers, will spread
the load out amoung them.
This commit was sponsored by Ethan Aubin.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
offer to back them up.
Only ask once per key.
This commit was sponsored by Thomas Hochstein on Patreon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--autostart mode currently only uploads queued keys, but it will later
be expanded to do more. Including checking the BackupRecord for problems
when necessary.
The autostart file is installed by keysafe --backup, so that when keysafe
is installed with stack, and used, it will make sure it autostarts in the
future.
The autostart file is installed by the Makefile too. This will later
let --autostart check for keys that have not been backed up and prompt
about backing them up. This way, the user won't need to remember to run
keysafe to back things up.
Reused Utility.FreeDesktop from git-annex, and had to add some stuff it
depends on.
This commit was sponsored by Fernando Jimenez on Patreon.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
keysafe does not run as root, so the normal ext2 disk reserve will do
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mashed up a argon2-based PoW with token buckets and bloom filters.
This is intended to prevent a few abuses including:
* Using a keysafe server for general file storage, by storing a whole
lot of chunks.
* An attacker guessing names that people will use, and uploading junk
to keysafe servers under those names, to make it harder for others to use
keysafe later.
* An attacker trying to guess the names used for objects on keysafe
servers in order to download them and start password cracking.
(As a second level of defense, since the name generation hash
is expensive already.)
Completely untested, but it builds!
This commit was sponsored by Andreas on Patreon.
|
| |
|
| |
|
| |
|
|
|
|
| |
controlling terminal and zenity was not installed.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
f2fa457a7e45721e94a3f5d0307faf874150cdb4 did in fact fix a laziness issue
in the benchmark. This explains why restore was taking so long, although
I need to re-run a real restore to double-check this.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Used a Purism Librem 13. The name generation hash was already ok,
but the key encryption key hash was quite off.
This is not a total blazing top of the line server, but that's ok;
keysafe's hashes are intended to be tuned for commodity hardware.
It should not take a user more than an hour to restore a key.
The spotAWS value is adjusted because AWS's c4.8xlarge instances run at
up to 3.5Ghz, compared with the 2.20Ghz of the Librem 13. Basically
it's one Moore's doubling ahead of the reference laptop.
|