[Bug 332095] New: Legacy encryption support does not work at all
https://bugzilla.novell.com/show_bug.cgi?id=332095 Summary: Legacy encryption support does not work at all Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: opensuse@dstoecker.de QAContact: qa@suse.de Found By: --- I have a system with following entries in fstab: /dev/private1 /media/hd1 reiserfs sync,noauto,users,exec,loop,encryption=twofish256 0 0 /dev/private2 /media/hd2 reiserfs sync,noauto,users,exec,loop,encryption=twofish 0 0 /dev/private3 /media/hd3 reiserfs sync,noauto,users,exec,loop,encryption=twofish256 0 0 /dev/private4 /media/hd4 reiserfs sync,noauto,users,exec,loop,encryption=twofish256 0 0 /home/user/SData /media/sdata ext3 sync,noauto,users,exec,loop,encryption=twofish256 0 0 With nothing I try, I can access these partition under 10.3. a) Normal mount (previous method used on 10.2) does not work: - causing segfault (yes, mount segfaults) - does nothing after password request - cannot find file system (modules loop_fish2, cryptoloop and twofish_common loaded before). b) cryptosetup does not work: Test: losetup /dev/loop0 /home/user/SData cryptsetup create /dev/loop0 /media/sdata --cipher twofish-cbc-plain -s 256 -h sha512 Command failed: dm_task_set_name: Device /dev/loop0 not found Doing the same for the direct harddisk and non-loop files results in equal error messages like /dev/sdd not found or /dev/private4 not found. (/dev/privateX are links to either /dev/sdXY automatically generated by udev-rules). All methods I tried failed and I get out of options. According to docs all the methods I tried should work, but none does so. It's not very fine to have a new set of encryption problems in every new release. This bug blocks openSUSE 10.3 at all our work machines, as they use encrypted partitions as well as encrypted backup disks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c1 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.provo.novell.com |lnussel@novell.com Severity|Blocker |Normal Status|NEW |ASSIGNED --- Comment #1 from Ludwig Nussel <lnussel@novell.com> 2007-10-09 03:43:18 MST --- mount is not supposed to segfault. please open a separate bug report and provide a backtrace. your cryptsetup call is broken in two ways - you need to pass a name as 2nd parameter - if you volumes are really in loop_fish2 format you need to use twofish-cbc-null as algorithm See http://www.suse.de/~lnussel/hdencryption/hdencryption.html for examples. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c2 --- Comment #2 from Ludwig Nussel <lnussel@novell.com> 2007-10-09 03:45:49 MST --- note that confusing the loop_fish2 twofish256 and cryptoloops twofish256 can esp with reiserfs lead to severe filesystem corruption! take extra care, use a copy of the production images for testing!! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c3 --- Comment #3 from Dirk Stoecker <opensuse@dstoecker.de> 2007-10-09 04:04:36 MST --- You see in above fstab, that the test device I used for the examples uses twofish2, so the call is correct. The second argument can be everything, the result is the same. As there is no update-guide available commandline errors are possible, but as long as the systems tells me the device does not exist there is no real use in digging deeper into possible commandline problems (BTW I really tried lot's of different commandlines). Anyway the same problem appears for /dev/private2, which is an old twofish and thus uses twofish-cbc-null. The mount crash produces no backtrace, as I have no debug-stuff installed. The problem is so central, that I don't believe it is specific to my machine. I would start installing debug stuff and doing debugging only, when the easy reproducability tests on your side fail (especially as my 10.3 test system I talk about has no network access for easy installation). Regarding corruption: a) If encryption is correct, there is either a no-or-nothing. Wrong encryption cannot produce nearly correct results, but totally wrong results, else the encryption is not strong. The filesystem will no discover the partition at all then. b) Loading too many modules should not influence the results at all (BTW: I also tried with loading only subsets of the specified kernel modules, Result is the same). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c4 --- Comment #4 from Ludwig Nussel <lnussel@novell.com> 2007-10-09 04:35:20 MST --- Well, you are free to not believe me and make your own experience. The problem is not the decryption itself but the IV generation method. Choosing the wrong one results in subtle changes. Old images really do work, this one is from 8.1: # losetup /dev/loop0 oldimg # cryptsetup --hash ripemd160:20 --cipher twofish-cbc-null --key-size 192 create fff /dev/loop0 Enter passphrase: # mount /dev/mapper/fff /mnt/ # cat /mnt/motd Have a lot of fun... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c5 --- Comment #5 from Dirk Stoecker <opensuse@dstoecker.de> 2007-10-09 04:47:56 MST --- Nice. With this example I got it to work. Ok, this fixes one problem. Make an support data article from the comment 4 and put it somewhere on the openSUSE servers. I will try this evening, if I can access all my partitions using the dm-crypt method with cryptsetup. And BTW, how can I do this without root privileges? Everything regarding encryption in the support database is before 10.x if I remember correctly. But the other central problem still exists. The losetup based method fails, crashs, ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c6 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #6 from Ludwig Nussel <lnussel@novell.com> 2007-10-09 05:12:58 MST --- There currently is no way for users to set up dm-crypt devices. You'll have to put the volumes into crypttab and have them mounted during boot. Alternatively reformat them using LUKS, users can mount via hal then. That's the best choice anyways. The loop_fish2 format is really weak and shouldn't be used anymore. The losetup method doesn't officially work for loop_fish2 anymore. Support for encryption isn't available at all in upstream losetup btw. If you insist in the fstab method and the old image format you may try mount and losetup from 10.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c7 Dirk Stoecker <opensuse@dstoecker.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #7 from Dirk Stoecker <opensuse@dstoecker.de> 2007-10-09 05:42:57 MST --- Your second paragraph contradicts your release announcements. http://www.novell.com/linux/releasenotes/i386/openSUSE/10.3/RELEASE-NOTES.en... Search for: "It is still possible to use cryptoloop via losetup and mount." Regarding dm-crypt: This means you effectively want to kill the possibility to use already crypted user-file-containers, crypted external hard-disks, crypted backup-hard-disks and crypted disk-images (CD's), which very well worked on openSUSE before 10.3 and is heavy used throughout our company, as it is the only acceptable solution to keep the company secrets save in all the locations (home disks, external disks, backup spaces, ...)? You don't mean this. This is the third time SUSE changes the encryption setup, which means I now have 3 legacy setups (twofish, twofishSL92, twofish256) and now the LUKS stuff will come. The minimum I expect is that the legacy stuff works (and it seems your release note writers thought the same way). We have about 60 crypted backup DVS's, which cannot be reencrypted and about 20 crypted partitions only in the small development department of our company. Changing this is lots of work and only to see it changed again in SUSE 11.0, as there will be another oh-so-good new solution. The setups we use are no specific options, but main options of previous SUSE releases. We expect, that they still work. In 5 to 10 years you may be right, not now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c8 Dale Peters II <r3dlp@sbcglobal.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r3dlp@sbcglobal.net --- Comment #8 from Dale Peters II <r3dlp@sbcglobal.net> 2007-10-17 01:43:04 MST --- (In reply to comment #4 from Ludwig Nussel)
Well, you are free to not believe me and make your own experience. The problem is not the decryption itself but the IV generation method. Choosing the wrong one results in subtle changes.
Old images really do work, this one is from 8.1: # losetup /dev/loop0 oldimg # cryptsetup --hash ripemd160:20 --cipher twofish-cbc-null --key-size 192 create fff /dev/loop0 Enter passphrase: # mount /dev/mapper/fff /mnt/ # cat /mnt/motd Have a lot of fun...
Doing this would only address part of the problem: mounting an image that has already been created. However, doing these steps doesn't exactly address my issue (and the reason why I initially reported--and reopened--this bug). I was trying to initialize an encrypted, loopback filesytem via the following steps: dd if=~/linux-2.6.22.5-31.tbz of=~/rb bs=1k skip=321 count=2k losetup -e aes -k 2048 `losetup -f` ~/rb losetup -a mkfs -t ext3 `losetup -a | cut -d ":" -f 1` My issue is the second command fails (which the fourth one demonstrates), and this prevents me from being able to format the encrypted, loopback filesystem. So, we know that something isn't functioning correctly with losetup. Yet, until a few minutes ago, I hadn't tested to see if loopback filesystem support worked for non-encrypted filesystems. Here are the steps for my second test: sshfs root@172.16.0.6:/mnt/sdc1 /mnt/tmp mount -o loop,ro /mnt/tmp/stage2.img /mnt/jaz ls /mnt/jaz This worked just fine. Now let's see what happens if I try to create a non-encrypted, loopback filesystem via the following steps: dd if=/dev/zero of=~/rb bs=1k count=2k losetup `losetup -f` ~/rb losetup -a mkfs -t ext3 `losetup -a | cut -d ":" -f 1` mount `losetup -a | cut -d ":" -f 1` /mnt/tmp ls /mnt/tmp This worked just fine too. So, it's definitely an issue with the crypto-code portion of the losetup codebase. If losetup is considered legacy, then what else should we use for creating (and mounting [which I believe invokes the losetup code]) loopback filesystems? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=332095#c9 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #9 from Ludwig Nussel <lnussel@novell.com> 2007-10-17 02:41:13 MST --- AES support a maximum key size of 256 bits. 2048 will not work of course. In PM with Dirk we concluded that all partitions are accessible with dm-crypt so the original claim of this bug is still INVALID. Please move further discussions to the opensuse-* mailinglists and do not reopen this bug. Anyways, an upcoming util-linux update will include a patch for mount/losetup so "twofish" or "twofishSL92" are recognized. A warning that those methods are deprecated will be printed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com