| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
This is useful both to test the server throttling of uploads, and to make
it harder for servers to know if an object actually contains secret key
information.
This commit was sponsored by Brock Spratlen on Patreon.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Share download cannot be due to wrong password
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This only affects time estimates while keysafe is generating hashes;
it does not affect cost estimates to brute-force.
|
|
|
|
|
| |
This way, the tor hidden service using it will be the only way it's
exposed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This changed the storage format, not that it matters because nobody is
using it yet.
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
User has to remember they did this and use the same configuration on
restore.
|
| |
|
| |
|
|
|
|
|
| |
Don't need to check key server for --gpgkeyid backup, because the same
switch has to be provided at restore time.
|
| |
|
| |
|
| |
|
|
|
|
| |
also, restore actually works!
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Needed to verify decryption puzzles
|
| |
|
|
|
|
|
|
|
|
| |
It only adds 1 minute GPU time to each crack attempt, on top of the 10
minutes CPU time needed to argon2 the password. Since my implementation of
the AES puzzle is currently really slow, this is not worth it.
Will revisit when I have a faster AES library to use, or a better puzzle.
|
|
|
|
|
|
|
|
| |
Not a good idea to use IV, because all the parts of the IV that are 0
will not obscure the data in the first block at all.
Instead, sha256 the password to generate the IV, and keep the puzzle as
part of the key.
|
| |
|