gocryptfs/internal/cryptocore, branch v1.4Mirror of gocryptfs source code on Githubhttp://nuetzlich.net/cgit/gocryptfs/atom?h=v1.42017-06-11T19:29:50+00:00cryptocore: prefetch nonces in the background2017-06-11T19:29:50+00:00Jakob Unterwurzacher2017-06-11T17:56:59+00:00urn:sha1:9837cb0ddc5c38af9916a2a6a580092caf952e59
Spawn a worker goroutine that reads the next 512-byte block
while the current one is being drained.
This should help reduce waiting times when /dev/urandom is very
slow (like on Linux 3.16 kernels).
cryptocore: prefetch nonces in 512-byte blocks2017-06-09T20:05:14+00:00Jakob Unterwurzacher2017-06-09T19:52:26+00:00urn:sha1:80516ed3351477793eec882508969b6b29b69b0a
On my machine, reading 512-byte blocks from /dev/urandom
(same via getentropy syscall) is a lot faster in terms of
throughput:
Blocksize Throughput
16 28.18 MB/s
512 83.75 MB/s
For a single-threaded streaming write, this drops the CPU usage of
nonceGenerator.Get to almost 1/3:
flat flat% sum% cum cum%
Before 0 0% 95.08% 0.35s 2.92% github.com/rfjakob/gocryptfs/internal/cryptocore.(*nonceGenerator).Get
After 0.01s 0.092% 92.34% 0.13s 1.20% github.com/rfjakob/gocryptfs/internal/cryptocore.(*nonceGenerator).Get
This change makes the nonce reading single-threaded, which may
hurt massively-parallel writes.
cryptocore: remove lastNonce check2017-06-07T21:08:43+00:00Jakob Unterwurzacher2017-06-07T21:08:43+00:00urn:sha1:d2be22a07f32d5c41223419314c9fb6b8ad2ab42
This check would need locking to be multithreading-safe.
But as it is in the fastpath, just remove it.
rand.Read() already guarantees that the value is random.
cryptocore: improve comments and add tests for hkdfDerive2017-05-27T12:41:20+00:00Jakob Unterwurzacher2017-05-27T12:41:20+00:00urn:sha1:d6ef283c3f076ba45dd873d69e1c7d86ed29b14a
These should make it easier to re-implement the key derivation
that was enabled with the "HKDF" feature flag.
fix golint complaints2017-04-29T12:50:58+00:00Jakob Unterwurzacher2017-04-29T12:50:58+00:00urn:sha1:edb3e19cb5543c580261052395d461fa47c7cf58Add -forcedecode2017-04-23T21:11:56+00:00danim72017-04-08T00:09:28+00:00urn:sha1:f1945c4daae65074cfca8f0ab5b97ac5a50c24a0
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
media.
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
full stack: implement HKDF support2017-03-05T20:59:55+00:00Jakob Unterwurzacher2017-03-05T20:59:55+00:00urn:sha1:d0bc7970f721cee607d993406d97d32e2c660abe
...but keep it disabled by default for new filesystems.
We are still missing an example filesystem and CLI arguments
to explicitely enable and disable it.
configfile: switch to 128-bit IVs for master key encryption2017-03-05T17:03:03+00:00Jakob Unterwurzacher2017-03-05T17:03:03+00:00urn:sha1:b7328815183b7a4ff37156085fb78e8e86aff165
There is no security reason for doing this, but it will allow
to consolidate the code once we drop compatibility with gocryptfs v1.2
(and earlier) filesystems.
Drop Go 1.4 compatability code everywhere2017-03-05T16:44:14+00:00Jakob Unterwurzacher2017-03-05T16:44:14+00:00urn:sha1:966308eeb7793a4a8ca578e160981e3b059b82e6
Yields a nice reduction in code size.
cryptocore: rename "BackendTypeEnum" -> "AEADTypeEnum"2017-03-05T16:10:57+00:00Jakob Unterwurzacher2017-03-05T16:08:16+00:00urn:sha1:874e4fb5e911cc3654b4bd314f3bef764aa39b74
There are two independent backends, one for name encryption,
the other one, AEAD, for file content.
"BackendTypeEnum" only applies to AEAD (file content), so make that
clear in the name.