FS#18619 - loop-aes removed from util-linux-ng - but no smooth migration?
Attached to Project:
Arch Linux
Opened by Thanassis Tsiodras (ttsiodras) - Tuesday, 09 March 2010, 14:39 GMT
Last edited by Dan Griffiths (Ghost1227) - Tuesday, 09 March 2010, 20:02 GMT
Opened by Thanassis Tsiodras (ttsiodras) - Tuesday, 09 March 2010, 14:39 GMT
Last edited by Dan Griffiths (Ghost1227) - Tuesday, 09 March 2010, 20:02 GMT
|
Details
Description:
Support for loop-AES was removed from util-linux-ng, at revision 71260 of the trunk. Because of that, people (like me) lost their access to encrypted partitions and CD/DVDs. I won't argue in favour of loop-AES - even though it *is* faster (see here: http://dev.riseup.net/grimoire/storage/encryption/benchmarks/dmcrypt-v-loopaes/) but I will argue in favour of a handover procedure: If such actions must be taken, there should be a clear "migration" procedure - in this case, a way to mount storage encrypted with loop-AES with the remaining technology, i.e. cryptsetup. Is there such a recipe? Or am I supposed to recompile my own version of util-linux-ng every time I upgrade? Or re-burn a series of DVDs, re-encode huge partitions with multimedia, etc? Additional info: * version: util-linux-ng 2.17.1-1 dropped support for loop-AES, at revision trunk:71260 * config and/or log files etc: Not applicable Steps to reproduce: From a pre-2.17 version of util-linux-ng, use loop-AES to encrypt a partition, a DVD, etc. Upgrade to util-linux-ng 2.17.1-1, and the mount command no longer understand "aes256" as an option for the loop device... |
This task depends upon
Closed by Dan Griffiths (Ghost1227)
Tuesday, 09 March 2010, 20:02 GMT
Reason for closing: Not a bug
Additional comments about closing: OP requested close. Info regarding a work around is in last few posts
Tuesday, 09 March 2010, 20:02 GMT
Reason for closing: Not a bug
Additional comments about closing: OP requested close. Info regarding a work around is in last few posts
The fact that we ever added this patch to util-linux(-ng) was against Arch policies, as loop-aes will never be merged upstream. I don't know when and why this was done.
If I add "IgnorePkg=util-linux-ng" to my /etc/pacman.conf, will the universe come crashing down?
Salvation for us loop-AES users is found here: http://glarson.org/files/loopaes/
I just tested this with my loop-AES volume (aes256) and it worked perfectly.
In case the original script is lost, it breaks down (for my aes256 volumes) to
1. installing "hashalot" from AUR
and
2. This:
sh# losetup /dev/loop0 /path/to/whatever/file/or/volume
sh# blockdev --getsize /dev/loop0
8192
(used further below, watch for 8192)
sh# hashalot -x -n 32 sha512
Enter passphrase:
2dabf0570ea5f5a19b612c116075e2e0f165c3cb79df6718a6aeefd262687d37
(this is just an example output, not the output of my real key, so don't bother :-)
sh# echo 0 8192 crypt aes-plain 2dabf0570ea5f5a19b612c116075e2e0f165c3cb79df6718a6aeefd262687d37 \
0 /dev/loop0 0 | dmsetup create crypted
sh# mount /dev/mapper/crypted /mnt/heaven
Enjoy!
P.S. Is there a more appropriate place where we can put this info - for other poor souls that search for it?
sh# losetup /dev/loop0 /path/to/whatever/file/or/volume
sh# cryptsetup -c aes-plain -h sha512 create crypted /dev/loop0
Enter passphrase:
sh# mount /dev/mapper/crypted /mnt/heaven
There - busted.