287 reputation
110
bio website xavierm02.net
location France
age 21
visits member for 2 years, 4 months
seen Nov 22 at 21:15

French. Loves JavaScript.


May
10
comment Running several times the same command with several aguments after a pipe
@Gilles : I asked a new question there: crypto.stackexchange.com/questions/16109/…
May
9
comment Running several times the same command with several aguments after a pipe
I want to protect all data at rest with a password and a keyfile and be able to back up the keyfile using secret sharing. This implies that I can't encrypt the keyfile with the password because otherwise, I would have to replace all the backups everytime I changed the password. The only other way to require both is to derive a key from both (atm using xor). And I have any tools I want available since I can just add hooks to make update-initramfs add things to the ramfs. Aside from the derivation method, there is no real choice, unless I want to mess with dm-crypt directly, and I don't.
May
9
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
(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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
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
comment Running several times the same command with several aguments after a pipe
I will :) I'm just making sure it works first. And since the program isn't as simple as I made it look, it's taking time :)
May
8
comment Running several times the same command with several aguments after a pipe
It does, thank you :)
May
8
comment Running several times the same command with several aguments after a pipe
You're writing the keys to several files. I want to use the key to decrypt several files..
May
6
comment XOR of a shell variable and a binary file
I did go with C. You're saying I should use stream. But since I have two inputs (for the xor part) I don't see how I could do that. (For the rest of it, I guess it'd be possible)
May
6
comment XOR of a shell variable and a binary file
You code would be much easier to read if you used variables instead of having this expression with a printf printing a printf... Anyway, I'll accept this answer but still go with the C binary since it will be way faster.
May
5
comment XOR of a shell variable and a binary file
@Patrick : I was just pointing out that I do not lose security with the XOR. Knowing that the last bytes are A-Z or 0-9 in ASCII is information. Knowing that the last bytes are that XORed with some random data is not. So using concatenation leaks some information about the result key while XOR doesn't. I don't know if this information can be used or not and it depends on how the key is used. But the XOR method can't be much weaker (because the length difference is small) but can be much stronger (because the probability distribution is uniform).
May
5
comment XOR of a shell variable and a binary file
@Patrick : I transform 4096 random bits + 8*l of far from random bits to 4096 random bits. The length is reduced a bit and maybe that reduces security a little bit but maybe it increases it a lot because I don't know how cryptsetup encrypts the masterkey but that algorithm might not like having not-so-random data in the key. Also, I'm not doing a one-time pad here. If you concatenate both, the resulting key immediately gives you both keys. If you XOR both, you get the result of the XOR, I change the password and you get it again, you would know the XOR of my two passwords...
May
5
comment XOR of a shell variable and a binary file
@derobert : I could use secret sharing to combine the keyfile and the passphrase but it seems like overkill. I will be using it for the backup of the keyfile though :)
May
5
comment XOR of a shell variable and a binary file
@Patrick : Because the passphrase is a very specific kind of data and I don't think concatenating it with a random file (given that cryptsetup won't know it's a password since I give it as a file and will treat it as a file where each byte can be anything). I know an XOR will be at least as strong as a concatenation and I know it's feasable (worst case senario I have to write my own C executable).
May
5
comment XOR of a shell variable and a binary file
@derobert : I want to be able to backup parts of the keyfile in several geographically distant places. If I encrypted it with the password, getting those backups would allow to bypass the password (if I backed the non-encrypted version) or would force me to update all the backups whenever I changed the password (of I backed the encrypted version) so it's not exactly what I want and while trying to do it, I found out that I'd have to mess with the initramfs to make it work so while I'm at it, I could just get the two passwords myself and give it a new password computed with those two.