| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
This commit was sponsored by Ignacio 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Needed for efficient serialization of shares, unless upstream takes my
suggestion to make the finite field be size 256.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
