public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Stefan G. Weichinger" <lists@xunil.at>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: gentoo-user@lists.gentoo.org,
	Daniel Troeder <daniel@admin-box.com>,  walt <w41ter@gmail.com>,
	Florian Philipp <lists@f_philipp.fastmail.net>,
	 Jason Dusek <jason.dusek@gmail.com>,
	Till Maas <opensource@till.name>,
	hanno@gentoo.org
Subject: Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
Date: Tue, 18 May 2010 23:49:40 +0200	[thread overview]
Message-ID: <4BF30B74.9090807@xunil.at> (raw)
In-Reply-To: <alpine.LSU.2.01.1005182237370.14710@obet.zrqbmnf.qr>

Am 18.05.2010 23:16, schrieb Jan Engelhardt:
> yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
>> 
>> I saved my history, unfortunately only the last steps were kept,
>> but I am able to reconstruct:
>> 
>> The block-device is /dev/VG01/sgwcrypt ...
>> 
>> #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom`
> 
> Well, I'm not going to blame you yet, but the shell is pretty 
> binary-unsafe -- and you have just invoked that voodoo again.
> 
> # head -c79 /dev/urandom >t-crypt.ukey; \ hexdump -C <t-crypt.ukey;
> \ KEY=$(cat t-crypt.ukey); \ echo -n "$KEY" | hexdump -C; \ echo -n
> "$KEY" | wc; 00000000  a4 b2 c8 a0 4f c9 00 37  66 f3 0c 20 2d 5c 05
> e7  |....O..7f.. -\..| 00000010  cd 5e 5d 00 5d e1 18 2a  1a 8b 2d 41
> 22 e7 66 0e  |.^].]..*..-A".f.| 00000020  b0 a3 1d 41 1e 23 1d 00  f8
> b2 b2 bc 34 28 94 fe  |...A.#......4(..| 00000030  ba 0f 45 11 b5 c6
> d8 a1  ca c2 ec 08 5e 48 d4 7f  |..E.........^H..| 00000040  17 a8 75
> af ef ef f1 7a  0f 2f bf 64 c2 3a 9c     |..u....z./.d.:.| 0000004f
> 
> 00000000  a4 b2 c8 a0 4f c9 37 66  f3 0c 20 2d 5c 05 e7 cd
> |....O.7f.. -\...| 00000010  5e 5d 5d e1 18 2a 1a 8b  2d 41 22 e7 66
> 0e b0 a3  |^]]..*..-A".f...| 00000020  1d 41 1e 23 1d f8 b2 b2  bc 34
> 28 94 fe ba 0f 45  |.A.#.....4(....E| 00000030  11 b5 c6 d8 a1 ca c2
> ec  08 5e 48 d4 7f 17 a8 75  |.........^H....u| 00000040  af ef ef f1
> 7a 0f 2f bf  64 c2 3a 9c              |....z./.d.:.| 0000004c 0
> 2      76
> 
> So what was once 79 bytes has been reduced to 76 by means of the $() 
> or backtick operator.
> 
> Not a problem for the crypto utilities per se, but I wanted to point
> out that you are effectively only having a 76-long key here. The
> chance to get a key shorter than the requested 79 is 27%.
> 
>> # avoid newline here echo -n $KEY | openssl aes-256-cbc >
>> /etc/security/super.key
>> 
>> # format it, using "--keyfile=-" as mentioned in bugs ... openssl
>> aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v 
>> --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat 
>> /dev/VG01/sgwcrypt
>> 
>> # open it openssl aes-256-cbc -d -in /etc/security/super.key |
>> cryptsetup -v --key-file=-  luksOpen /dev/VG01/sgwcrypt newhome
> 
> Turns out cryptsetup has yet another oddity. With LUKS, --key-file=-
> is moot. Instead....
> 
> [fkey is the unencrypted one]
> 
> # cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \ cryptsetup
> --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey Key slot 0
> unlocked.
> 
> 
> And you thought that doc/bugs.txt described all cryptsetup CLI
> oddities.
> 
> *facepalm*
> 
> ANYWAY.
> 
> 
> If I proceed with this luks container now, all succeeds:
> 
> # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... #
> cryptsetup remove x94
> 
> First, let's see if raw passthrough works:
> 
> # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as
> dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
>  # df /mnt Filesystem           1K-blocks      Used Available Use%
> Mounted on /dev/loop94              62465      5365     53875  10%
> /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt
> 
> 
> Now the openssl-encrypted file:
> 
> # ./mount.crypt -vo
> keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
> /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
> '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
> _dev_loop94 as dmdevice name command: 'mount' '-n'
> '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
> 1K-blocks      Used Available Use% Mounted on /dev/loop94
> 62465      5365     53875  10% /mnt
> 
> 
> Match?

Frankly: dunno ;-)
Yes, I am able to follow and understand in general so far ... but ...

Assuming that "I am too stupid": Where is the how-to-do-it?

So far the only thing I really understood "You are doing it wrong".

But where is the "Do it this way and you are safe" ?

I wouldn't post here if I were competent enough to know all these details.

Concerning encryption I am at the USER-level, you know for sure ;-)

Just trying to feed back my problems to maybe detect bugs or my mistakes.

Stefan



  reply	other threads:[~2010-05-18 21:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-16 12:36 [gentoo-user] Re: Kernel upgrade and now LUKS failure Jan Engelhardt
2010-05-17  9:14 ` Stefan G. Weichinger
2010-05-17 21:01   ` Daniel Troeder
2010-05-18 13:05   ` Jan Engelhardt
2010-05-18 13:44     ` Stefan G. Weichinger
2010-05-18 16:04       ` Jan Engelhardt
2010-05-18 16:56         ` Stefan G. Weichinger
2010-05-18 17:57           ` Jan Engelhardt
2010-05-18 18:57             ` Stefan G. Weichinger
2010-05-18 19:33               ` Stefan G. Weichinger
2010-05-18 20:06                 ` Jan Engelhardt
2010-05-18 20:17                   ` Stefan G. Weichinger
2010-05-18 21:16                     ` Jan Engelhardt
2010-05-18 21:49                       ` Stefan G. Weichinger [this message]
2010-05-18 22:23                         ` Jan Engelhardt
2010-05-20 10:25                           ` Stefan G. Weichinger
2010-05-20 13:40                             ` Stefan G. Weichinger
2010-05-23 20:37                               ` [gentoo-user] SOLVED: " Stefan G. Weichinger
2010-05-23 21:57                                 ` Mick
2010-05-25 18:44                                   ` Stefan G. Weichinger
2010-05-18 19:38               ` [gentoo-user] " Eray Aslan
2010-05-21 20:24             ` Daniel Troeder
  -- strict thread matches above, loose matches on Subject: below --
2010-05-03 16:56 [gentoo-user] " Jason Dusek
2010-05-04 10:06 ` Stefan G. Weichinger
2010-05-04 16:54   ` [gentoo-user] " walt
2010-05-04 17:38     ` Stefan G. Weichinger
2010-05-04 19:28       ` Stefan G. Weichinger
2010-05-04 21:24         ` Daniel Troeder
2010-05-05  4:42           ` Stefan G. Weichinger
2010-05-05  8:00             ` Daniel Troeder
2010-05-05  8:42               ` Stefan G. Weichinger
2010-05-05 19:39                 ` Daniel Troeder
2010-05-05 20:17                   ` Stefan G. Weichinger
2010-05-05 20:23                     ` Stefan G. Weichinger
2010-05-06 16:24                       ` Daniel Troeder
2010-05-06 18:38                         ` Stefan G. Weichinger
2010-05-07  8:53                           ` Stefan G. Weichinger
2010-05-07 14:24                             ` Stefan G. Weichinger
2010-05-07 21:14                               ` Stefan G. Weichinger
2010-05-10 16:48                                 ` Daniel Troeder
2010-05-04 23:51       ` walt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF30B74.9090807@xunil.at \
    --to=lists@xunil.at \
    --cc=daniel@admin-box.com \
    --cc=gentoo-user@lists.gentoo.org \
    --cc=hanno@gentoo.org \
    --cc=jason.dusek@gmail.com \
    --cc=jengelh@medozas.de \
    --cc=lists@f_philipp.fastmail.net \
    --cc=opensource@till.name \
    --cc=w41ter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox