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
Currently the master key is stored in the super block and can be unlocked by a key which is derived from a sequence provided via direct input, file or stdin.
Since the overwriting of sectors can be hard to control (mostly relevant for SSD / flash storage) it would be nice to be able to provide the key directly. It then could be stored on different encrypted media to chain-unlock the bcachefs volume or stored on some detachable device.
Otherwise a master key with a compromised passphrase might remain accessible via the old passphrase, even after changing it.
To my knowledge ChaCha20 keys have no specific key requirements (any cryptographically random sequence of 32 bytes will do) so I see no reason speaking against providing a key directly (except for not being able to tell whether the key is valid, but that's the user's problem for this mode in my view.) dm-crypt (--key-file=- --hash=plain --type=plain) and ZFS (keyformat=raw keylocation=file://...) support this use case.
I could also live with a master key that is derived from some input, but providing the master key directly would be most desirable.
My least favourite option would be to simply be able to store the encrypted master key in some other location. This would be similar to dm-crypt with LUKS and a detached header.
Are there any plans for such changes yet or is there anything speaking against them?
I think I found wishlist items which are somewhat related like "secure delete" and "support for multiple key slots", although they would not directly cover what I'm looking for.
The text was updated successfully, but these errors were encountered:
Currently the master key is stored in the super block and can be unlocked by a key which is derived from a sequence provided via direct input, file or stdin.
Since the overwriting of sectors can be hard to control (mostly relevant for SSD / flash storage) it would be nice to be able to provide the key directly. It then could be stored on different encrypted media to chain-unlock the bcachefs volume or stored on some detachable device.
Otherwise a master key with a compromised passphrase might remain accessible via the old passphrase, even after changing it.
To my knowledge ChaCha20 keys have no specific key requirements (any cryptographically random sequence of 32 bytes will do) so I see no reason speaking against providing a key directly (except for not being able to tell whether the key is valid, but that's the user's problem for this mode in my view.)
dm-crypt
(--key-file=- --hash=plain --type=plain
) andZFS
(keyformat=raw keylocation=file://...
) support this use case.I could also live with a master key that is derived from some input, but providing the master key directly would be most desirable.
My least favourite option would be to simply be able to store the encrypted master key in some other location. This would be similar to dm-crypt with
LUKS
and a detached header.Are there any plans for such changes yet or is there anything speaking against them?
I think I found wishlist items which are somewhat related like "secure delete" and "support for multiple key slots", although they would not directly cover what I'm looking for.
The text was updated successfully, but these errors were encountered: