Few questions from a new user
Quoted 7 lines · Iggy
Would you mind explaining hash-spec? Meaning that there is no internal mechanism to use different hashes/detect which has was used on a given volume?
Thanks for your time!
-Iggy
(Follow-up to the list, because others may wonder this too, also correction, as I posted nonsense. Sorry about that.)
If you look at the header specification linked here:
http://code.google.com/p/cryptsetup/wiki/Specification
in Figure 1 you find the cipher and mode for the actual disk encryption, and the "hash-spec" which is the hash-function used by PBKDF2.
Sorry, I was confused yesterday, you can change the hash. (I had just though about PBKDF2 which you cannot easily change to, say, scrypt...)
Now the thing is that while you can change SHA-1 to, say, SHA-512, the attacks on SHA-1 are preimage collisions, i.e. you can find two input values that hash to the same value. That means an attacker could possibly create a second passphrase for one he already knows in plain which is not useful and hence this vulnerability of SHA-1 has no effect. (Actually this even is harder, I am simplifying here...)
What these attacks are useful for is, for example, creating two certificates with different identities in them but the same hash. Then you can have one signed by some authority, but use the otehr one with the different identity in it as the auhority signs the hash, not the actual identity in the certificate. For MD5, this is really easy. For SHA-1 it is just about becomming feasible.
But this is completely useless for reversing a hash and that is what an attacker would need to do in LUKS. And he would need to reverse an iterated hash, iterated, e.g., 200'000 times on my test machine. Reversing a hash is usually only possible by brute-force, attacks that make this much easier require very serious flaws in the hash. There are no such attacks for SHA-1 that I am aware of, and certainly none for an iterated SHA-1.
So changing the hash does not do anything, really as the attacker can only try to brute-force the passphrase and that takes the same effort for SHA-1 and for SHA-512.
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare
Quoted 12 lines
If you look at the header specification linked here:
http://code.google.com/p/cryptsetup/wiki/Specificationin Figure 1 you find the cipher and mode for the actual disk encryption, and the "hash-spec" which is the hash-function used by PBKDF2.
Sorry, I was confused yesterday, you can change the hash. (I had just though about PBKDF2 which you cannot easily change to, say, scrypt...)
Thanks for the clarification,your comment seemed to be in contradiction with what i was understanding from reading the spec and i even peeked at cryptsetup source code to make a sense of your comment before giving up because i was spending too much time on something that will amount to nothing.
Quoted 5 lines
So changing the hash does not do anything, really as the attacker can only try to brute-force the passphrase and that takes the same effort for SHA-1 and for SHA-512.
cryptsetup 1.6.0 changed default cipher mode from cbc to xts not because cbc had practical issues but because xts was becoming a standard[1].Sometimes it makes sense to be where everybody else is if being anywhere is just as good as being anywhere else.If it makes not practical difference btw SHA1 and SHA2,then moving away from SHA1 seem like a good idea with the reason being having one less thing to explain in the FAQ.
[1] http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6409
Quoted 5 lines · .. ink ..
Quoted 5 lines
So changing the hash does not do anything, really as the attacker can only try to brute-force the passphrase and that takes the same effort for SHA-1 and for SHA-512.
Quoted 8 lines
cryptsetup 1.6.0 changed default cipher mode from cbc to xts not because cbc had practical issues but because xts was becoming a standard[1].Sometimes it makes sense to be where everybody else is if being anywhere is just as good as being anywhere else.If it makes not practical difference btw SHA1 and SHA2,then moving away from SHA1 seem like a good idea with the reason being having one less thing to explain in the FAQ.
[1] http://comments.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6409
CBC has issues that XTS avoids and some of them are pretty practical, for example the watermark attack. SHA1 has no such issues as it is used in LUKS.
Sorry, but changing default algorithms to reduce questions by people is about the worst possible reason to do it.
Also, I do not see the questions by people as such a bad thing. We can point them in the right direction and maybe learn a thing or two about what concerns LUKS users have and maybe some of them actually read parts of the FAQ.
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. --Tony Hoare
Quoted 6 lines · Arno Wagner
If you look at the header specification linked here:
http://code.google.com/p/cryptsetup/wiki/Specificationin Figure 1 you find the cipher and mode for the actual disk encryption, and the "hash-spec" which is the hash-function used by PBKDF2.
Just one more addition - specified hash algorithm (in hash-spec header field) is also used in LUKS anti-forensic filter.
Also there using SHA1 causes no problem, AF solves different problem there (split key into multiple sectors). See spec above as well.
Milan