Timeline for Running several times the same command with several arguments after a pipe
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:36 | history | edited | CommunityBot | replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/ | |
| Apr 26, 2016 at 20:49 | comment | added | Wildcard | @xavierm02, you are indeed rolling your own crypto, which is a very very very very bad idea. | |
| May 9, 2014 at 17:55 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 | added 3 characters in body |
| May 9, 2014 at 17:55 | comment | added | Gilles 'SO- stop being evil' | @xavierm02 You need $(…) to store the result into a variable instead of displaying it on the terminal. print -rn -- is in case the value looks like an option to echo. But all this is for zsh anyway, which is not something you're likely to have available at the point where you want to run cryptsetup. | |
| May 9, 2014 at 17:46 | comment | added | xavierm02 | What's the reason for using print -rn instead of echo -n? And do I really need to do $(get_key) instead of get_key? | |
| May 9, 2014 at 16:28 | comment | added | xavierm02 | (it=cryptsetp). About the memory, I still don't understand. The password is in memory and I XOR it but reading the file character per character and outputing the result as soon as it's ready. Imagine a 10GB keyfile. I will never have it all in memory but will still be able to compute the xor since it needs just one character at a time. Anyway, not having it in memory isn't a requirement. It's just something that might improve security. | |
| May 9, 2014 at 16:23 | comment | added | xavierm02 | I don't get why the entropy of the password needs to be spread. The fact that the keyfile is random makes the output random, whether you know the password, just how it looks or nothing about it. Think of it that way: It would be secure if I gave it just the password. But I want to require the keyfile too so I XOR the password with the keyfile. The entropy of the result is strictly larger than the entropy of the password alone. There could be a problem is it sliced the password and used different parts of it for different things but it doesn't: it uses a key derivation function on it. | |
| May 9, 2014 at 15:55 | comment | added | Gilles 'SO- stop being evil' | @xavierm02 Regarding input to the C program, the input is in memory. You might xor one copy with the key, but even after that there are probably other copies lying around, until the program exits. And the key itself of course is in cryptsetup's memory, and in the kernel itself. You can't protect against an attacker who can get a RAM dump (except by arranging for the key to remain solely in the CPU cache, but that's hard). | |
| May 9, 2014 at 15:52 | comment | added | Gilles 'SO- stop being evil' | @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. | |
| May 9, 2014 at 15:40 | comment | added | xavierm02 | The key file feature only allows a keyfile, not a key file and a password so I have to produce a keyfile that depends on my keyfile and the password anyway. That's what I'm doing but I have it read the file from stdin. | I'm thinking of trying to switch to your way of doing it because otherwise, making a "change password" thing is really annoying: prompting when you have pipes everywhere and background processes is a bit hard. | |
| May 9, 2014 at 15:38 | comment | added | xavierm02 | The keyfile is quite long. The C program reads a character from the keyfile, one from stdin and then outputs the xor of those two chars. It doesn't keep it in memory. It might stay a bit longer because of the output buffer but then it gets transferred to cryptsetup. And I don't think the buffer is big enough to retain the whole key. | Why is it not a good way? If you concatenate them, your resulting key has a regognizable pattern: random stuff followed by human-readable characters. If you xor them, you have no information on the resulting key. | |
| May 9, 2014 at 1:45 | comment | added | Gilles 'SO- stop being evil' | @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. | |
| May 9, 2014 at 1:34 | comment | added | xavierm02 | The keyfile is obvously on a usb key that doesn't remain near the computer obviously. Worst case senario: cryptsetup waits for the whole key and this way of doing it is as secure as yours. Best case senario: it doesn't and the key is never all in memory and the places where it is placed is then used for the rest of it so recovering the whole key from memory is impossible. | |
| May 9, 2014 at 1:32 | comment | added | xavierm02 | 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. | |
| May 9, 2014 at 0:40 | comment | added | Gilles 'SO- stop being evil' | @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.) | |
| May 9, 2014 at 0:36 | comment | added | xavierm02 | 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 :) | |
| May 9, 2014 at 0:19 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |