| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
