Mirror of gocryptfs source code on Github http://nuetzlich.net/cgit/gocryptfs/atom?h=v1.4.3 2017-08-21T19:06:05+00:00 2017-08-21T19:06:05+00:00 Jakob Unterwurzacher 2017-08-21T19:06:05+00:00 urn:sha1:ed046aa35978c835d79f9cb3ee359349ee9145c5 https://goreportcard.com/report/github.com/rfjakob/gocryptfs#misspell 2017-08-16T16:33:00+00:00 Jakob Unterwurzacher 2017-08-16T16:33:00+00:00 urn:sha1:312ea32bb70abb93be315d0b7c442d5c4ae571d9 The benchmark that supported the decision for 512-byte prefetching previously lived outside the repo. Let's add it where it belongs so it cannot get lost. 2017-08-11T17:02:26+00:00 Jakob Unterwurzacher 2017-08-11T16:42:30+00:00 urn:sha1:0c520845f3623eff28f0277a52e3ccffd928f5c2 Remove the "Masterkey" field from fusefrontend.Args because it should not be stored longer than neccessary. Instead pass the masterkey as a separate argument to the filesystem initializers. Then overwrite it with zeros immediately so we don't have to wait for garbage collection. Note that the crypto implementation still stores at least a masterkey-derived value, so this change makes it harder, but not impossible, to extract the encryption keys from memory. Suggested at https://github.com/rfjakob/gocryptfs/issues/137 2017-07-14T21:22:15+00:00 Jakob Unterwurzacher 2017-07-14T21:22:15+00:00 urn:sha1:ccf1a84e417e9f7d83f31c61c44cf3851703b1e4 On MacOS, building and testing without openssl is much easier. The tests should skip tests that fail because of missing openssl instead of aborting. Fixes https://github.com/rfjakob/gocryptfs/issues/123 2017-06-11T19:29:50+00:00 Jakob Unterwurzacher 2017-06-11T17:56:59+00:00 urn: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). 2017-06-09T20:05:14+00:00 Jakob Unterwurzacher 2017-06-09T19:52:26+00:00 urn: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. 2017-06-07T21:08:43+00:00 Jakob Unterwurzacher 2017-06-07T21:08:43+00:00 urn: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. 2017-05-27T12:41:20+00:00 Jakob Unterwurzacher 2017-05-27T12:41:20+00:00 urn:sha1:d6ef283c3f076ba45dd873d69e1c7d86ed29b14a These should make it easier to re-implement the key derivation that was enabled with the "HKDF" feature flag. 2017-04-29T12:50:58+00:00 Jakob Unterwurzacher 2017-04-29T12:50:58+00:00 urn:sha1:edb3e19cb5543c580261052395d461fa47c7cf58 2017-04-23T21:11:56+00:00 danim7 2017-04-08T00:09:28+00:00 urn: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 .