| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 0f0aa21ea11f6eae368326b178d4c3eaf5cc5186.
Dunno why, but this prevents it printing anything. Needs investigation.
|
|
|
|
|
|
| |
Socks can throw exceptions at connection time, and these are not caught
by the ExceptT, so catch at a higher level, and catch all exceptions to
prevent the client crashing.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
gpg2 2.1.15 seems to have added some new fields to the --with-colons
--list-secret-keys output. These include "fpr" and "grp", and come before
the "uid" line. So, the parser was giving up before it saw the name. Fix by
continueing to look for the uid line until the next "sec" line.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Simplifies code, uses less memory, and don't need to protect
against flooding generation of RequestIDs, since the server does not store
them at all.
Note that the RequestIDSecret is only stored in ram, so restarting the
server will invalidate any RequestIds given out before. It would be
possible now to store that on disk to avoid that problem, but probably not
worth it.
|
| |
|
|
|
|
|
|
|
|
| |
Once on the queue, requests should not need to contend with other requests
that are not on the queue, so added a fallback request bucket.
tokenBucketWait is not fair, so ensure FIFO processing of the queue by
using a FairRWLock.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Now caps total request rate even if attacker is willing to burn infinite
CPU on PoW.
|
| |
|
| |
|
|
|
|
| |
This reverts commit 48ec718a6211a71ae0a796eb1c3a6ea091dc6e14.
|
| |
|
| |
|
|
|
|
| |
keysafe does not run as root, so the normal ext2 disk reserve will do
|
| |
|
|
|
|
|
|
| |
This decreases the possible maximumStorageRate by half, down from
10 gb/month to 5 gb/month. Which is probably a tolerable amount for
many servers; that's 16 months to fill up a terabyte disk.
|
|
|
|
|
|
|
| |
(down from 7 to 4)
This decreases the possible maximumStorageRate by half, down from
18 gb/month to 10 gb/month.
|
| |
|
| |
|
|
|
|
|
| |
This avoids a 1s delay in requests, except when an attacker is flooding
them.
|
| |
|
| |
|
|
|
|
| |
In this case, an empty string is hashed to generate the PoW.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|