[Replying to
http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 ]

On 2010-05-05 08:00:43 GMT, Daniel Troeder wrote:
>On 05/05/2010 06:42 AM, Stefan G. Weichinger wrote:
>> Am 04.05.2010 23:24, schrieb Daniel Troeder:
>>
>>> I'm using sys-fs/cryptsetup-1.1.1_rc1 since 02.05.2010 and didn't have
>>> any issues.
>>> Please decrypt your partition from the command line, so we can see if it
>>> is a cryptsetup/luks/kernel problem or a pam_mount problem.
>>>
>>> Cmdline should something like:
>>> $ sudo cryptsetup -d /etc/security/verysekrit.key luksOpen
>>> /dev/mapper/VG01-crypthome myhome
>>> Which should create /dev/mapper/myhome.
>>
>> My user sgw is currently not allowed to sudo this (should it be? it
>> never was).
>>
>> And for root it says "Kein Schlüssel mit diesem Passsatz verfügbar."
>> (german) which should be "No key available with this passphrase." in
>> english.
>That is a message from cryptsetup. As you are using openssl to get the
>key, I think the problem might be there.
>
>I followed the guide you linked here (website is down, but google-cache
>works:
>http://webcache.googleusercontent.com/search?q=cache:7eaSac72CoIJ:home.coming.dk/index.php/2009/05/20/encrypted_home_partition_using_luks_pam_+encrypted _home_partition_using_luks_pam&cd=2&hl=de&ct=clnk& gl=de&client=firefox-a)
>and it works for me (kernel is 2.6.33-zen2):
>
>lvcreate -n crypttest -L 100M vg0
>KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79`
>echo $KEY | openssl aes-256-ecb > verysekrit.key
>openssl aes-256-ecb -d -in verysekrit.key

In my personal opinion, both the quality of shell commands and key
generation is suboptimal. What makes it bad is that people follow it.

First, it generates a key which does not exploit the entire space.
People claim it's because they want an ASCII readout, but frankly, you
get the same with `hexdump -C`.

Second, it's using echo without the -n parameter, thus implicitly
inserting a newline into the key -- which is the cause for yoru observed
mounting problems.

Third, because you are passing the key via stdin into cryptsetup, it
only uses the first line of whatever you pipe into it; whereas pam_mount
uses the entire keyfile as it is supposed to be.

(Fourth, the howto suggests ECB, which, well, looks rather weak
considering the ECB's Tux picture on Wikipedia.)

All of that should be in doc/bugs.txt, and mount.crypt even warns about
ECB. You really cannot ignore seeing that.

Phew!

Am 16.05.2010 14:36, schrieb Jan Engelhardt:
> [Replying to
> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542
> ]
>
> In my personal opinion, both the quality of shell commands and key
> generation is suboptimal. What makes it bad is that people follow
> it.
>
> First, it generates a key which does not exploit the entire space.
> People claim it's because they want an ASCII readout, but frankly,
> you get the same with `hexdump -C`.
>
> Second, it's using echo without the -n parameter, thus implicitly
> inserting a newline into the key -- which is the cause for yoru
> observed mounting problems.
>
> Third, because you are passing the key via stdin into cryptsetup, it
> only uses the first line of whatever you pipe into it; whereas
> pam_mount uses the entire keyfile as it is supposed to be.
>
> (Fourth, the howto suggests ECB, which, well, looks rather weak
> considering the ECB's Tux picture on Wikipedia.)
>
> All of that should be in doc/bugs.txt, and mount.crypt even warns
> about ECB. You really cannot ignore seeing that.
>
> Phew!

Jan, thanks for your suggestions.

I created a new LUKS-volume and tried to avoid all the mentioned
pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.

The new volume is not mounted with pam_mount-2.1, but mounted OK with
pam_mount-1.33.

And, btw, as mentioned in the original thread, I use CBC, not ECB ;-)

-- Your CCing Daniel didn't work maybe, wrong address, I corrected it
for this reply)

-- I CC: hanno@gentoo.org to link to the gentoo bug

http://bugs.gentoo.org/show_bug.cgi?id=318865

Thanks, regards, Stefan

On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote:
> Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>> [Replying to
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542
>> ]
>>
>> In my personal opinion, both the quality of shell commands and key
>> generation is suboptimal. What makes it bad is that people follow
>> it.
>>
>> First, it generates a key which does not exploit the entire space.
>> People claim it's because they want an ASCII readout, but frankly,
>> you get the same with `hexdump -C`.
>>
>> Second, it's using echo without the -n parameter, thus implicitly
>> inserting a newline into the key -- which is the cause for yoru
>> observed mounting problems.
>>
>> Third, because you are passing the key via stdin into cryptsetup, it
>> only uses the first line of whatever you pipe into it; whereas
>> pam_mount uses the entire keyfile as it is supposed to be.
>>
>> (Fourth, the howto suggests ECB, which, well, looks rather weak
>> considering the ECB's Tux picture on Wikipedia.)
>>
>> All of that should be in doc/bugs.txt, and mount.crypt even warns
>> about ECB. You really cannot ignore seeing that.
>>
>> Phew!
>
> Jan, thanks for your suggestions.
>
> I created a new LUKS-volume and tried to avoid all the mentioned
> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.
>
> The new volume is not mounted with pam_mount-2.1, but mounted OK with
> pam_mount-1.33.
>
> And, btw, as mentioned in the original thread, I use CBC, not ECB ;-)
>
> -- Your CCing Daniel didn't work maybe, wrong address, I corrected it
> for this reply)
>
> -- I CC: hanno@gentoo.org to link to the gentoo bug
>
> http://bugs.gentoo.org/show_bug.cgi?id=318865
>
> Thanks, regards, Stefan
>
Hello

In a more general discussion I wonder what the advantage of using a SSL
encrypted key for HDD-encryption is.

As the SSL-keyfile is as well protected as the password to decrypt it is
"difficult", so would be a directly encrypted HDD with the same password
- or not?

If this assumption is correct, then I think the direct approach would be
better, as in "less complexity - less errors".

<For the paranoid>
I think it is much easier to hide a trojan/keylogger on an unencrypted
root-partition than in an initramfs - and not be detected. (Both is easy
to do, but the latter can be detected easier.) Unfortunately that
detection is never done... after opening the root-dev some form of
file-/partition-manipulation check should run. Though the kernel could
be already compromised... Only a secure boot-path like with TCG is
really secure... well this is only if you fear strong attackers, and not
only loosing your notebook I head that really strong attackers would
hide a keylogger beneath your keyboard... but if you have that kind of
opponent, then you really have other problems too
</For the paranoid>

Anyway - if your /tmp is not encrypted you should put it on a ram-disk:
gives you speed and privacy in case of robbery. Also important is to
have the screensaver lock the screen.

On a technical note: I use "xts" as I read it's a good (although new) algo.

Bye,
Daniel


BTW: No need to CC mailing list mails to me - I'll read and reply the
ML-thread when I have time


--
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887

On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote:
>Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>> [Replying to
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542
>> ]
>>
>> Second, it's using echo without the -n parameter, thus implicitly
>> inserting a newline into the key -- which is the cause for yoru
>> observed mounting problems.
>>
>> Third, because you are passing the key via stdin into cryptsetup, it
>> only uses the first line of whatever you pipe into it; whereas
>> pam_mount uses the entire keyfile as it is supposed to be.
>>[...]
>Jan, thanks for your suggestions.
>
>I created a new LUKS-volume and tried to avoid all the mentioned
>pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.

To be sure, use

openssl -d ... | hexdump -C

to detect newlines in the key. The shell has far too many occasions
where
gets stripped or added.

Am 18.05.2010 15:05, schrieb Jan Engelhardt:
>
> On Monday 2010-05-17 11:14, Stefan G. Weichinger wrote:
>> Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>>> [Replying to
>>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542
>>> ]
>>>
>>> Second, it's using echo without the -n parameter, thus implicitly
>>> inserting a newline into the key -- which is the cause for yoru
>>> observed mounting problems.
>>>
>>> Third, because you are passing the key via stdin into cryptsetup, it
>>> only uses the first line of whatever you pipe into it; whereas
>>> pam_mount uses the entire keyfile as it is supposed to be.
>>> [...]
>> Jan, thanks for your suggestions.
>>
>> I created a new LUKS-volume and tried to avoid all the mentioned
>> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.
>
> To be sure, use
>
> openssl -d ... | hexdump -C
>
> to detect newlines in the key. The shell has far too many occasions
> where
gets stripped or added.

Thanks for the hint.

Could you please show me an example how it should look like and what to
look for?

I get several lines of output, that seems bad ... ?

Maybe I didn't get all the steps right, could be.

Do you know any howto where it is done "the right way"?

Thanks, Stefan

On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote:
>>
>> To be sure, use
>>
>> openssl -d ... | hexdump -C
>>
>> to detect newlines in the key. The shell has far too many occasions
>> where
gets stripped or added.
>
>Thanks for the hint.
>
>Could you please show me an example how it should look like and what to
>look for?

In case the key is a suboptimal ascii-only key, it looks like this.

offset bytes broken up visual represent.
00000000 35 34 28 5e 52 69 4c 22 3c 72 4c 35 35 27 70 32 |54(^RiL"<rL55'p2|
00000010 39 59 48 21 3b 50 2e 25 52 6e 27 4f 4d 51 42 6b |9YH!;P.%Rn'OMQBk|
00000020 34 43 38 76 4e 49 51 24 3f 5e 42 63 2f 6c 2d 76 |4C8vNIQ$?^Bc/l-v|
00000030 34 7d 4d 6a 50 5c 41 3c 3f 70 76 67 22 57 21 6b |4}MjPA<?pvg"W!k|
00000040 77 78 5c 24 23 5e 2e 56 7a 56 24 5a 4f 7e 6a |wx$#^.VzV$ZO~j|
0000004f

If there were a newline, one of the bytes would be 0a.

>Do you know any howto where it is done "the right way"?

The right and easy way is to just use the supplied pmt-ehd(8) tool,
which works both interactively and non-interactively, depending on
whether it's called with enough arguments or not, so there's something
for everybody's flavor.
It does not do LUKS yet as of pam_mount 2.2, though. Guess my
todo list gets longer..

Am 18.05.2010 18:04, schrieb Jan Engelhardt:
>
> On Tuesday 2010-05-18 15:44, Stefan G. Weichinger wrote:
>>>
>>> To be sure, use
>>>
>>> openssl -d ... | hexdump -C
>>>
>>> to detect newlines in the key. The shell has far too many occasions
>>> where
gets stripped or added.
>>
>> Thanks for the hint.
>>
>> Could you please show me an example how it should look like and what to
>> look for?
>
> In case the key is a suboptimal ascii-only key, it looks like this.
>
> offset bytes broken up visual represent.
> 00000000 35 34 28 5e 52 69 4c 22 3c 72 4c 35 35 27 70 32 |54(^RiL"<rL55'p2|
> 00000010 39 59 48 21 3b 50 2e 25 52 6e 27 4f 4d 51 42 6b |9YH!;P.%Rn'OMQBk|
> 00000020 34 43 38 76 4e 49 51 24 3f 5e 42 63 2f 6c 2d 76 |4C8vNIQ$?^Bc/l-v|
> 00000030 34 7d 4d 6a 50 5c 41 3c 3f 70 76 67 22 57 21 6b |4}MjPA<?pvg"W!k|
> 00000040 77 78 5c 24 23 5e 2e 56 7a 56 24 5a 4f 7e 6a |wx$#^.VzV$ZO~j|
> 0000004f
>
> If there were a newline, one of the bytes would be 0a.

Will check ...

>> Do you know any howto where it is done "the right way"?
>
> The right and easy way is to just use the supplied pmt-ehd(8) tool,
> which works both interactively and non-interactively, depending on
> whether it's called with enough arguments or not, so there's something
> for everybody's flavor.
> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
> todo list gets longer..

:-)

But given the fact that I store the key on the same hard-disk with the
shadowed user-pw I could also leave that openssl-part straight away,
correct?? seems the same level of (in)security to me ...

thank you, Stefan

On Tuesday 2010-05-18 18:56, Stefan G. Weichinger wrote:
>
>>> Do you know any howto where it is done "the right way"?
>>
>> The right and easy way is to just use the supplied pmt-ehd(8) tool,
>> which works both interactively and non-interactively, depending on
>> whether it's called with enough arguments or not, so there's something
>> for everybody's flavor.
>> It does not do LUKS yet as of pam_mount 2.2, though. Guess my
>> todo list gets longer..
>
>:-)
>
>But given the fact that I store the key on the same hard-disk with the
>shadowed user-pw I could also leave that openssl-part straight away,
>correct?? seems the same level of (in)security to me ...

Yes. The point of keyfiles is to be able to change the password on
a volume.

Without a keyfile, a crypto program would take the password, hash it
somehow, and you get your AES key. Changing the password means having
a different AES key, meaning decrypting the disk will yield a
different result. In other words, changing the password would require
at least reading the old data, reencrypting it and writing it again.
Takes time.

With a keyfile, you retain the same AES key all the time, and encrypt
the AES key itself - reencrypting the AES key is quick, as it's
only some xyz bits, not terabytes.

Am 18.05.2010 19:57, schrieb Jan Engelhardt:

>> But given the fact that I store the key on the same hard-disk with the
>> shadowed user-pw I could also leave that openssl-part straight away,
>> correct?? seems the same level of (in)security to me ...
>
> Yes. The point of keyfiles is to be able to change the password on
> a volume.
>
> Without a keyfile, a crypto program would take the password, hash it
> somehow, and you get your AES key. Changing the password means having
> a different AES key, meaning decrypting the disk will yield a
> different result. In other words, changing the password would require
> at least reading the old data, reencrypting it and writing it again.
> Takes time.
>
> With a keyfile, you retain the same AES key all the time, and encrypt
> the AES key itself - reencrypting the AES key is quick, as it's
> only some xyz bits, not terabytes.

Ok, I see. So my current setup with one disk only and SSL-generated
keyfile does not add security but flexibility (being able to switch
passwords more quickly).

Do you see a way of getting this working with my current packages:

pam_mount-2.1
sys-fs/cryptsetup-1.1.1_rc2

and LUKS ... ?

As mentioned the old keyfile works with pam_mount-1.33, when I check the
changelog at

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/pam_mount/ChangeLog?view=markup

this is a package from 10 Jan 2010, so maybe it wouldn't be too risky to
just mask >pam_mount-1.33

-

On the other hand I would like to get that done right, sure.

Any howto without pmt-ehd that would keep me safe from newlines etc
(btw. there were NO newlines in that hexdump-output)?

Thanks for your time, Stefan

Am 18.05.2010 20:57, schrieb Stefan G. Weichinger:

> On the other hand I would like to get that done right, sure.
>
> Any howto without pmt-ehd that would keep me safe from newlines etc
> (btw. there were NO newlines in that hexdump-output)?

Created a new encrypted LV and used "--key-file=-" as mentioned in:

http://pam-mount.git.sourceforge.net/git/gitweb.cgi?p=pam-mount/pam-mount;a=blob;hb=master;f=doc/bugs.txt

Still no success with 2.x ...
I masked pam_mount-2.x again ...

Stefan