4 ms·

> As a general principle, as a user, I expect a file on one computer to be usable on another computer. As a general rule, I expect a file on an encrypted disk

> As a general principle, as a user, I expect a file on one computer to be usable on another computer. As a general rule, I expect a file on an encrypted disk to be unreadable for anyone who lacks the encryption key(s). > if I need to obtain some other thing from the original computer to "unlock" that file, I should be able to do it. You can export your passwords to a plain text CSV from the original computer.

ftchd 15d ago
As a general rule, if I'm the user of both disks I expect to have the encryption key(s).
shaky-carrousel 15d ago
As a general rule, I expect a file on an encrypted disk to be encrypted with a key derived from a password I provide.
- wtallis 15d ago
  I think it's time to update your expectations. Hardware security modules have been around for quite a while. You shouldn't assume that your chosen password is the only input to the key derivation, or even that the raw key itself will always be obtainable.
  - shaky-carrousel 15d ago
    I never assumed that my chosen password was the only input to the key derivation. Just that my chosen password is at least one of the inputs to the key derivation. LUKS has been around for quite a while.
    - wtallis 15d ago
      You're asking for the encryption key to be derivable by an unrelated system that only has the encrypted file and your password.
      - shaky-carrousel 14d ago
        No, I'm asking for what LUKS has done for two decades. Keyslots are alternatives, not requirements, so a TPM slot and a passphrase slot coexist and either one alone unwraps the master key. BitLocker does the same with key protectors. Even on a local account with no internet, there's always a 48-digit recovery password that opens the volume on a completely different machine. Two of the three major platforms ship a portable passphrase path alongside the hardware one, so this being unavailable here is a product decision, not a law of key derivation.
      - josephcsible 14d ago
        Yes, that's kind of what you need to be able to successfully back up and restore an encrypted file. Why are you making it sound like that's such a strange thing to want?
      - winstonwinston 14d ago
        The sane way for encryption keys stored in hardware (secure enclave or tpm like) is to onboard user when the key is not derived from user password. Just like they do for FDE to export a recovery key and then you can adjust your expectations when you know (been told) whats going on.
      - kelnos 14d ago
        Yes, in general that's how I expect (or at least want) things to work. And I'm a tech-savvy software developer. Your average non-technical user will absolutely expect it to work this way, and if it doesn't, will be at best confused, and at worst incredibly angry that their photos are gone.
josephcsible 15d ago
The right way to do that is FDE, where you can't even mount the filesystem to see the files without having the decryption key.
frizlab 14d ago
> You can export your passwords to a plain text CSV from the original computer. Exporting a private key from a keychain is hard to automate (the password of the keychain is asked for all exports, and HAS to be typed manually IIRC).

ftchd 15d ago

As a general rule, if I'm the user of both disks I expect to have the encryption key(s).

shaky-carrousel 15d ago

As a general rule, I expect a file on an encrypted disk to be encrypted with a key derived from a password I provide.

wtallis 15d ago
I think it's time to update your expectations. Hardware security modules have been around for quite a while. You shouldn't assume that your chosen password is the only input to the key derivation, or even that the raw key itself will always be obtainable.
- shaky-carrousel 15d ago
  I never assumed that my chosen password was the only input to the key derivation. Just that my chosen password is at least one of the inputs to the key derivation. LUKS has been around for quite a while.
  - wtallis 15d ago
    You're asking for the encryption key to be derivable by an unrelated system that only has the encrypted file and your password.
    - shaky-carrousel 14d ago
      No, I'm asking for what LUKS has done for two decades. Keyslots are alternatives, not requirements, so a TPM slot and a passphrase slot coexist and either one alone unwraps the master key. BitLocker does the same with key protectors. Even on a local account with no internet, there's always a 48-digit recovery password that opens the volume on a completely different machine. Two of the three major platforms ship a portable passphrase path alongside the hardware one, so this being unavailable here is a product decision, not a law of key derivation.
    - josephcsible 14d ago
      Yes, that's kind of what you need to be able to successfully back up and restore an encrypted file. Why are you making it sound like that's such a strange thing to want?
    - winstonwinston 14d ago
      The sane way for encryption keys stored in hardware (secure enclave or tpm like) is to onboard user when the key is not derived from user password. Just like they do for FDE to export a recovery key and then you can adjust your expectations when you know (been told) whats going on.
    - kelnos 14d ago
      Yes, in general that's how I expect (or at least want) things to work. And I'm a tech-savvy software developer. Your average non-technical user will absolutely expect it to work this way, and if it doesn't, will be at best confused, and at worst incredibly angry that their photos are gone.

josephcsible 15d ago

The right way to do that is FDE, where you can't even mount the filesystem to see the files without having the decryption key.

frizlab 14d ago

> You can export your passwords to a plain text CSV from the original computer. Exporting a private key from a keychain is hard to automate (the password of the keychain is asked for all exports, and HAS to be typed manually IIRC).