| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This pushes back the birthday bound for collisions to make it virtually
irrelevant.
|
|
...and minimal comment changes.
|
|
This patch also splits off Mkdir and Rmdir into its own file.
Fixes issue #8, thanks to @diseq for the bug report.
|
|
|
|
|
|
|
|
Results of cryptfs/openssl_benchmark.bash :
Before:
BenchmarkEnc_OpenSSL_4k_AES256_nonce96-2 50000 31802 ns/op 127.28 MB/s
BenchmarkEnc_OpenSSL_4k_AES256_nonce128-2 50000 32110 ns/op 126.06 MB/s
After:
BenchmarkEnc_OpenSSL_4k_AES256_nonce96-2 50000 28612 ns/op 141.47 MB/s
BenchmarkEnc_OpenSSL_4k_AES256_nonce128-2 50000 28613 ns/op 141.47 MB/s
|
|
|
|
This makes sure writing to a file fails early if the underlying
filesystem does not support fallocate. It also prevents partial header
write due to ENOSPC.
|
|
Creating the config file can fail easily, for example if the
password is not entered the same twice. This would leave an
orphaned gocryptfs.diriv behind.
|
|
|
|
Another 3x performance boost for applications that walk the
directory tree.
Excerpt from performance.txt:
VERSION UNTAR LS RM
v0.4 48 1.5 5
v0.5-rc1 56 7 19
v0.5-rc1-1 54 4.1 9
v0.5-rc1-2 45 1.7 3.4 <---- THIS VERSION
|
|
Formerly, we called decryptPath for every name.
That resulted in a directory walk that reads in all diriv files
on the way.
Massive improvement for RM and LS (check performance.txt for details)
VERSION UNTAR RM LS
v0.4 48 5 1.5
v0.5-rc1 56 19 7
v0.5-rc1-1 54 9 4.1 <---- THIS VERSION
|
|
Use that option to speed up the automated tests by 7 seconds.
Before:
ok github.com/rfjakob/gocryptfs/integration_tests 26.667s
After:
ok github.com/rfjakob/gocryptfs/integration_tests 19.534s
|
|
Times the impact of the parameter "N" to scrypt.
Results on a 2.7GHz Pentium G630:
gocryptfs/cryptfs$ go test -bench=.
PASS
BenchmarkScrypt10-2 300 6021435 ns/op ... 6ms
BenchmarkScrypt11-2 100 11861460 ns/op
BenchmarkScrypt12-2 100 23420822 ns/op
BenchmarkScrypt13-2 30 47666518 ns/op
BenchmarkScrypt14-2 20 92561590 ns/op ... 92ms
BenchmarkScrypt15-2 10 183971593 ns/op
BenchmarkScrypt16-2 3 368506365 ns/op
BenchmarkScrypt17-2 2 755502608 ns/op ... 755ms
ok github.com/rfjakob/gocryptfs/cryptfs 18.772s
|
|
It decrypted all file names using the root directory iv
|
|
|
|
|
|
(unused so far)
|
|
|
|
|
|
|
|
This file should only be readable by the owner and never be written to.
|
|
A file never gets a cipherSize <= HEADER_LEN in normal operation.
However, this can happen if header write it interrupted or the
underlying filesystem does not support fallocate.
Noticed while trying to store a CIPHERDIR in another gocryptfs mount
(gocryptfs does not support fallocate)
|
|
|
|
|
|
|
|
|
|
|
|
// List of feature flags this filesystem has enabled.
// If gocryptfs encounters a feature flag it does not support, it will refuse
// mounting. This mechanism is analogous to the ext4 feature flags that are
// stored in the superblock.
FeatureFlags []string
|
|
|
|
Also run go fmt
|
|
Also, forbid access to "gocryptfs.conf" in the root dir.
|
|
|
|
Also, gather all the command line arguments into an anonymous struct
"args".
|
|
Move all the intelligence into the new file address_translation.go.
That the calculations were spread out too much became apparent when adding
the file header. This should make the code much easier to modify in the
future.
|
|
Format: [ "Version" uint16 big endian ] [ "Id" 16 random bytes ]
Quoting SECURITY.md:
* Every file has a header that contains a 16-byte random *file id*
* Each block uses the file id and its block number as GCM *authentication data*
* This means the position of the blocks is protected as well. The blocks
can not be reordered or copied between different files without
causing an decryption error.
|
|
|
|
This prevents that the user enters the password only to get an error
later.
|
|
|
|
...also adapt the cryptfs tests for 256 bit long keys
|
|
|
|
|
|
AES-256 seems to be becoming the industry standard. While AES-128 is
good enough for tens of years to come, let's follow suit and be extra
safe.
|
|
The shell wrapper sends gocryptfs into the background and waits for SIGUSR1
|
|
|
|
The old implementation of counting up from a random starting
point had the problem that is allowed an attacker to find out
the write order of the blocks.
|
|
|
|
"Offset" is unclear whether it is an offset from the start of file
or start of block. "Skip" seems much better.
|
