You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to provide an external key to encrypt the master key. That key will be encrypted with a key derived from the password to keep it safe.
This increases security because:
If we get access to the encrypted key which is encrypted with a key derived from the pass, we can brute-force the pass, which is less secure than a full random key
Not having access to the encrypted key leaves us with the sole option to generate all possible keys, which is a huge space than the possible values for password
Generate key
The key generate PATH command should require a pass, randomly generate an encryption key, and encrypt it with the key derived from the pass.
Then write it in a file at PATH
Also have a param like key generate --stdout to directly print the key to stdout, in case the user wants to use > file
Change password
key passwd PATH, which asks for old and new passes (with confirmation) and re-encrypts the external key.
Use key
Then, in the mount command, add a new param --key PATH and use pass to decrypt it.
Also, have a param --key-stdin if the user wants to use rencfs ... < key
In EncryptedFs and EncryptedFsFuse3
These should also accept an Option<SecretString> as the path to the external key alongside the password and use that to decrypt the master key.
Expire master key
Given we expire the master key from mem, we will save the external key path to OS's keyring so we can reload it again when we need to decrypt again the master key. It's safer than keeping it in memory as, in extreme situations, it's somehow not as complicated for an attacker to retrieve that from memory rather than from keyring.
When #261 is impl we should use the external key to encrypt KEK.
Warning
Update readme
The text was updated successfully, but these errors were encountered:
The idea is to provide an external key to encrypt the master key. That key will be encrypted with a key derived from the password to keep it safe.
This increases security because:
Generate key
The
key generate PATH
command should require a pass, randomly generate an encryption key, and encrypt it with the key derived from the pass.key generate --stdout
to directly print the key tostdout
, in case the user wants to use> file
Change password
key passwd PATH
, which asks for old and new passes (with confirmation) and re-encrypts the external key.Use key
Then, in the mount command, add a new param
--key PATH
and use pass to decrypt it.Also, have a param
--key-stdin
if the user wants to userencfs ... < key
In
EncryptedFs
andEncryptedFsFuse3
These should also accept an
Option<SecretString>
as the path to the external key alongside the password and use that to decrypt the master key.Expire master key
Given we expire the master key from mem, we will save the external key path to OS's keyring so we can reload it again when we need to decrypt again the master key. It's safer than keeping it in memory as, in extreme situations, it's somehow not as complicated for an attacker to retrieve that from memory rather than from keyring.
When #261 is impl we should use the external key to encrypt
KEK
.Warning
Update readme
The text was updated successfully, but these errors were encountered: