Age | Commit message (Collapse) | Author |
|
Add an option to specify user verification options for `fido2-assert -t`
Options will be saved to config file
Provide same functionality to #705 with simpler implementation
Resolve #702
|
|
|
|
Feature flag + numeric paramater
https://github.com/rfjakob/gocryptfs/issues/499
|
|
The rewritten openssl backend does not support this flag anymore,
and it was inherently dangerour. Drop it (ignored for compatibility)
|
|
Commit
69d88505fd7f4cb0d9e4f1918de296342fe05858 go mod: declare module version v2
translated all instances of "github.com/rfjakob/gocryptfs/" to
"github.com/rfjakob/gocryptfs/v2/".
Unfortunately, this included hyperlinks.
Unbreak the hyperlinks like this:
find . -name \*.go | xargs sed -i s%https://github.com/rfjakob/gocryptfs/v2/%https://github.com/rfjakob/gocryptfs/v2/%
|
|
Commit f3c777d5eaa682d878c638192311e52f9c204294 added the `-devrandom` option:
commit f3c777d5eaa682d878c638192311e52f9c204294
Author: @slackner
Date: Sun Nov 19 13:30:04 2017 +0100
main: Add '-devrandom' commandline option
Allows to use /dev/random for generating the master key instead of the
default Go implementation. When the kernel random generator has been
properly initialized both are considered equally secure, however:
* Versions of Go prior to 1.9 just fall back to /dev/urandom if the
getrandom() syscall would be blocking (Go Bug #19274)
* Kernel versions prior to 3.17 do not support getrandom(), and there
is no check if the random generator has been properly initialized
before reading from /dev/urandom
This is especially useful for embedded hardware with low-entroy. Please
note that generation of the master key might block indefinitely if the
kernel cannot harvest enough entropy.
We now require Go v1.13 and Kernel versions should have also moved on.
Make the flag a no-op.
https://github.com/rfjakob/gocryptfs/issues/596
|
|
Have the information in one centralized place,
and access it from main as needed.
|
|
We used to do validation using lists of mandatory feature flags.
With the introduction of XChaCha20Poly1305, this became too
simplistic, as it uses a different IV length, hence disabling
GCMIV128.
Add a dedicated function, Validate(), with open-coded validation
logic.
The validation and creation logic also gets XChaCha20Poly1305
support, and gocryptfs -init -xchacha now writes the flag into
gocryptfs.conf.
|
|
Our git version is v2+ for some time now, but go.mod
still declared v1. Hopefully making both match makes
https://pkg.go.dev/github.com/rfjakob/gocryptfs/v2 work.
All the import paths have been fixed like this:
find . -name \*.go | xargs sed -i s%github.com/rfjakob/gocryptfs/%github.com/rfjakob/gocryptfs/v2/%
|
|
Drop Create and rename Create2 to Create.
|
|
The argument list got too long.
Part 1: Replace with Create2
|
|
And store it in gocryptfs.conf (=remove DirIV feature flag).
|
|
Result of:
$ gocryptfs -init foo
$ cat foo/gocryptfs.conf
Before:
{
"Creator": "gocryptfs v2.0.1",
"EncryptedKey": "FodEdNHD/cCwv1n5BuyAkbIOnJ/O5gfdCh3YssUCJ2DUr0A8DrQ5NH2SLhREeWRL3V8EMiPO2Ncr5IVwE4SSxQ==",
"ScryptObject": {
"Salt": "brGaw9Jg1kbPuSXFiwoxqK2oXFTgbniSgpiB+cu+67Y=",
"N": 65536,
"R": 8,
"P": 1,
"KeyLen": 32
},
"Version": 2,
"FeatureFlags": [
"GCMIV128",
"HKDF",
"DirIV",
"EMENames",
"LongNames",
"Raw64"
],
"FIDO2": {
"CredentialID": null,
"HMACSalt": null
}
}
After:
{
"Creator": "gocryptfs v2.0.1-5-gf9718eb-dirty.DerDonut-badnamecontent",
"EncryptedKey": "oFMj1lS1ZsM/vEfanNMeCTPw3PZr5VWeL7ap8Jd8YQm6evy2BAhtQ/pd6RzDx84wlCz9TpxqHRihuwSEMnOWWg==",
"ScryptObject": {
"Salt": "JZ/5mhy4a8EAQ/wDF1POIEe4/Ss38cfJgXgj26DuA4M=",
"N": 65536,
"R": 8,
"P": 1,
"KeyLen": 32
},
"Version": 2,
"FeatureFlags": [
"GCMIV128",
"HKDF",
"DirIV",
"EMENames",
"LongNames",
"Raw64"
]
}
|
|
|
|
|
|
This can happen on network drives: FRITZ.NAS mounted on MacOS returns
"operation not supported": https://github.com/rfjakob/gocryptfs/issues/390
|
|
master key.
Further raises the bar for recovering keys from memory.
|
|
Callers that do not want to decrypt the masterkey should
call plain Load().
https://github.com/rfjakob/gocryptfs/issues/258
|
|
Preparation for fixing https://github.com/rfjakob/gocryptfs/issues/258
|
|
Report the actual problem instead of a generic
"unexpected end of JSON input".
https://github.com/rfjakob/gocryptfs/issues/258
|
|
Before:
$ gocryptfs -fsck .
LoadConfFile: ReadFile: &os.PathError{Op:"open", Path:"/var/tmp/check-gocryptfs/scratchdev/gocryptfs.conf", Err:0xd}
Cannot open config file: open /var/tmp/check-gocryptfs/scratchdev/gocryptfs.conf: permission denied
After:
$ gocryptfs -fsck .
Cannot open config file: open /var/tmp/check-gocryptfs/scratchdev/gocryptfs.conf: permission denied
|
|
It is no longer printed at all when mounting a filesystem,
printing on -init can be disabled with -q.
https://github.com/rfjakob/gocryptfs/issues/76
|
|
TrezorPayload stores 32 random bytes used for unlocking
the master key using a Trezor security module. The randomness makes sure
that a unique unlock value is used for each gocryptfs filesystem.
|
|
configfile.LoadConfFile() -> configfile.Load()
configfile.CreateConfFile() -> configfile.Create()
|
|
readpassword.Trezor() is not implemented yet and returns
a hardcoded dummy key.
|
|
|
|
|
|
This will allows us to overwrite the password
with zeros once we are done with it.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
As soon as we don't need them anymore, overwrite
keys with zeros and make sure they run out of scope
so we don't create a risk of inadvertedly using all-zero
keys for encryption.
https://github.com/rfjakob/gocryptfs/issues/211
|
|
Allows to use /dev/random for generating the master key instead of the
default Go implementation. When the kernel random generator has been
properly initialized both are considered equally secure, however:
* Versions of Go prior to 1.9 just fall back to /dev/urandom if the
getrandom() syscall would be blocking (Go Bug #19274)
* Kernel versions prior to 3.17 do not support getrandom(), and there
is no check if the random generator has been properly initialized
before reading from /dev/urandom
This is especially useful for embedded hardware with low-entroy. Please
note that generation of the master key might block indefinitely if the
kernel cannot harvest enough entropy.
|
|
New codes:
* OpenConf = 23
* WriteConf = 24
|
|
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 .
|
|
|
|
Also adds a test to verify that they are set in new config
files.
|
|
This test fails because Raw64 has been disabled for now.
|
|
Raw64 is supported (but was disabled by default) since gocryptfs
v1.2. However, the implementation was buggy because it forgot
about long names and symlinks.
Disable it for now by default and enable it later, together
with HKDF.
|
|
...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.
|
|
As we have dropped Go 1.4 compatibility already, and will add
a new feature flag for gocryptfs v1.3 anyway, this is a good
time to enable Raw64 as well.
|
|
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.
|
|
|
|
Otherwise the next try to mount ends in
"ctlsock: listen unix ctl.sock: bind: address already in use"
|
|
Through base64.RawURLEncoding.
New command-line parameter "-raw64".
|
|
For convenience for the user, add a newline at the end.
Reported as #51 .
|
|
Requested at https://github.com/rfjakob/gocryptfs/issues/28
|
|
|
|
Also pull all the deterministic nonce code into fusefrontend_reverse
to greatly simplify the normal code path.
|
|
GCM-SIV is not yet finalized, and the reference implemenation is
painfully slow at about 2 MB/s. Switch to AES-SIV.
|
|
Also delete the unused "dirIVNameStruct", found by deadcode.
|
|
This will be used for strong symlink encryption in reverse mode.
|
|
|