| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
New parameters are set to the old values and test suite passes so this
looks good.
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
This only affects time estimates while keysafe is generating hashes;
it does not affect cost estimates to brute-force.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
User has to remember they did this and use the same configuration on
restore.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Needed for efficient serialization of shares, unless upstream takes my
suggestion to make the finite field be size 256.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
