How to activate hash module?

Hello,

I am upgrading my entire system (openSUSE 11.1->11.4), and now I am
facing such a problem. I have hash module present in both systems, I can check it by executing:
ls /lib/modules/$(uname -r)/kernel/crypto

It is named the same. The hash module is _not_ present as loaded
module in both versions:

lsmod

However I can and I use this hash module in OS11.1 without any
problem, simply by executing cryptsetup (and there are no complains about my choice), but when I execute cryptsetup on OS11.4 then it says the used hash is not supported.

Just of curiosity I tried to load the module explicitly (modprobe)
in 11.4 and then execute cryptsetup again, but it still stated the hash is not supported.

So, the question is: how to activate this hash module (for the
record: in OS11.1 I didn't have to do anything about it)?

Thank you in advance. If it is not necessity, I would like to talk
about problem generally, not about this or that specific module.

Kind regards,

Not quite shure on that one, but as far as I know, newer cryptsetup is libgcrypt based, so you'll have to check if your libgcrypt implementation has compiled-in support for this particular hash algorithm you're trying to use.

There are two uses for hash - one is for userspace (LUKS and passphrase hashing in plain mode) and the second is used in ESSIV in kernel.

The best is paste error messages (add --debug) so it is clear what is the exact problem.

If it is about kernel part, dmcrypt is here simple user of cryptoAPI,
so it depends on the module autoloading.
(Better ask on kernel crypto list http://vger.kernel.org/vger-lists.html#linux-crypto )

Milan

Hello,

Thank you all for the answers.

Ok, it is ripemd 320.

Just in case, I repeat, that in OS11.1 I don't have to load it to use it. It simply works.

I loaded the modules in both cases, it appeared in /proc/crypto. The only difference I see is type. For OS11.1 it is listed as digest, for 11.4 as shash. Sizes are the same.

That step I would like to avoid, because I am afraid that if I forget I have custom kernel with update I can overwrite it.

Ironically, yesterday I considered Debian as replacement for Opensuse because of this issue (hoping that with Debian most advanced issues are solved).

I don't know how to check it, but I try to find out. Anyway, I was hoping for something opposite -- that architecture is modular, and you simply add/activate hash module, not recompile entire library.

Code 22: Requested LUKS hash ripemd320 is not supported.

Options used -v and --debug.

I use the hash as hash for dmcrypt, --hash ripemd320

Ok, thank you.

Kind regards,

...and you will be surprised with answer :)

It is for LUKS hash, so it is userspace, no kernel related thing. AFAIK gcrypt never supported rmd320 (only rmd160 - just checked git tree).

But because LUKS ignored -h switch in older versions (with hardcoded sha1), it probably quetly worked until you upgraded to newer cryptsetup, which now honors -h switch now.
(Hash switch was useful only for plain mapping for passphrase hashing.)

Easy to verify: run crypsetup luksDump and check "Hash spec".

I guess it is "sha1", if so, simply remove rmd320 hash option and it will work again.

Milan

Hello,

I am! :-(

You are 100% correct and thank you million times for help! The sad fact is I am example of blindly trusting other parties, that something actually works, when it does not.

If I may ask a bit off-topic question:
* you wrote "was", so now it is useful in general?
* what do you mean by "plain mapping"? (I googled with no success)

Once again, thank you very much, back to upgrading to OS11.4 ;-)

Kind regards,

"plain" mode means directly configured dmcrypt - no metadata on disk. In cryptsetup it is used in "create" command.

In this mode you either provide key directly or key is just hashed passhprase.

In LUKS, the encryption key is always generated from RNG (random number generator) and passhprase just unlocks and decrypts metadata area on disk, where is this key stored.

So for LUKS there is no passphrase hashing thus that parameter was not needed (in its former meaning).

But because LUKS uses a hash internally (in PBKDF2, AF splitter and key digest) (for exact description see http://code.google.com/p/cryptsetup/wiki/Specification)
and some people want to user different algorithm, this option
was added even for LUKS mode.
(But changing the hash means backward incompatible setting.)

side note: Still, no need to worry about SHA1 use here. Until SHA1 remains one-way function, it should not cause problems here. Collision resistance or second preimage is not problem for this use - even if you are able to find collision (with all the iterations), the worst situation I can imagine is that cryptsetup will accept this key (key digest), but because decrypted key is collision key, not real key, you will get garbage instead of real data.
For anti-forensic splitter are these attacks irrelevant as well.

Quite simplified - please correct me, if am I wrong here:-)

See above. I meant that -h is now used for LUKS as well, just doing something different. For plain mode (passphrase hashing) it remains exactly the same.

Milan

Thank you very much for all explanation, I am not crypto guy, so I need time to let this info sink in :-) Pity it is not included in such detail in man.

Thank you once again!

Kind regards,

You can find some more info in the FAQ.

Hmm. Maybe I should add an item "What is the difference between plain dm-crypt and LUKS mode?". Maybe later today or some time this week.

One thing with plain mode is that it gives you some level of deniability. If you claim "I wiped that partition with data from /dev/urandom", it is basically impossible to disprove this for plain dm-crypt. However, this is worth less than it seems, as all the states that can compell you to give them crypto keys can also imprison you or worse on mere the suspicion that you have encrypted data.

These states currently seem to be the UK, the US and various dictatorships. In most western countries you can use LUKS and just refuse to hand over the keys.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

I think I finally get it :-) -- plain dm-crypt is raw, direct mode (it is up to anybody to interpret the data as she/he/it likes) and LUKS mode is "managed" mode, when the data are flagged they are encrypted, so any 3rd party person/program can detect that fact.

Thank you for this clarification.

Kind regards,