| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Updated many dependencies, notably secret-sharing which dropped the dep on
polynomial, and so allows building with ghc 8.x.
Did not try to support building with older ghc because the semigroup-monid
transition would make it nontrivial.
Stackage lts-14.25 is a compromise, since the stack shipped in debian (even
unstable) is not able to handle newer ones.
This commit was sponsored by Eric Drechsel on Patreon.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This commit was sponsored by John Peloquin on Patreon.
|
| |
|
|
|
|
|
|
| |
Use raaz for random bytestring generation exclusively. It was already used
in all important places, but chaffing was using crypto-random.
Note that System.Random is used for delays during chaffing and
by random-shuffle.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
This changed the storage format, not that it matters because nobody is
using it yet.
|
| |
|
|
|
|
| |
The keyid used as a salt in the shardIdents does not prevent rainbow table
attacks, since it's often anyKey (""). The obscure name combined with the
username does make rainbow tables unlikely to be useful though.
|
| |
|
|
|
|
|
|
|
|
| |
It was probably ok to use the password, but it's certianly ok to use the
name:
* The name must be known if the shards have been reassembled to get to the
point of decrypting the sharded data.
* The name is unique, while a user might reuse a password for eg, storing
different versions of the same key.
|
| |
|
|
| |
also, restore actually works!
|
| | |
|
| |
|
|
| |
Needed to verify decryption puzzles
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
