Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

14
  • get_key prompts for a password so he won't get anything. And I'm not trying to protect data from someone having a virus on my computer or access to it while it's on. I'm trying to protect it from someone who would try to recover the data from the computer while off. And that someone wouldn't care what permissions your file has or where it was written. I did not know about that feature of ksh so thank you for that. But I still like the idea of never having the whole key written linearly in memory so I'll do it Joseph's way. +1 though :) Commented May 9, 2014 at 0:36
  • 1
    @xavierm02 Warning: your security model is flawed. If the key is in the memory of get_key, or of decrypt, or in a pipe, it's still in memory! Putting it in the memory of zsh or perl doesn't make things worse. To counter someone who would steal the disk, as I indicate, make sure that the temporary file is on an in-memory filesystem. (An encrypted filesystem would also do fine.) Commented May 9, 2014 at 0:40
  • It's not. get_key asks for a password, calls a C program (xor) with via stdin (but the password is in memory). The C program returns the xor of the key and the keyfile it reads (and I don't think he even has all the keyfile in memory). Which is piped to cryptsetup. In short decrypt device means promt_password | xor keyfile | cryptsetup luksOpen -d - device. I don't think it will ever be all in memory, or at least not in the part of the process I control. Commented May 9, 2014 at 1:32
  • 1
    @xavierm02 No, the key is quite obviously in the memory of the C program, since it's producing the key as output. Where else did you think the key was, if it wasn't in memory? Oh, and also, ouch! Xor is not a good way of masking a key with a password. Since you're using cryptsetup, use its key file feature. You're falling into the trap of rolling your own cryptography and doing a much worse job than the standard tools. Commented May 9, 2014 at 1:45
  • 1
    @xavierm02 This is too long to explain in a comment, but in a nutshell: xor requires a password that's as long as the key, and doesn't spread entropy well because the password isn't uniformly random. You should use a key derivation function, with key stretching on the password. Commented May 9, 2014 at 15:52