headers
Gabriel Jägenstedt | 1 Apr 2005 14:35
Picon

Partitions on loopback

Hi all!

I've been spending several hours looking at ways to encrypt my computer.
I've read the Disc Encryption HOWTO and loop-aes readme but can't find
any information about how to partition up a loopback device with
partitions larger than 2GB. I have understood this should be easier with
kernel 2.6 but don't know anything more about it.

Are there any comprehensive guides on partitioning a to be encrypted
loopback device (device backed)? Or does anyone have any other tips?

For the record all I really want is a disc that is 100% totally
encrypted no partition tables showing or anything.

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/
Permalink | Reply | 18 comments |
headers
Jari Ruusu | 1 Apr 2005 15:36
Picon

Re: Partitions on loopback

Gabriel Jägenstedt wrote:
> I've been spending several hours looking at ways to encrypt my computer.
> I've read the Disc Encryption HOWTO and loop-aes readme but can't find
> any information about how to partition up a loopback device with
> partitions larger than 2GB. I have understood this should be easier with
> kernel 2.6 but don't know anything more about it.

loop-AES has supported 64 bit device offsets and sizelimits since November
29 2003. No 2GB limit on 2.4 or 2.6 kernels.

> Are there any comprehensive guides on partitioning a to be encrypted
> loopback device (device backed)? Or does anyone have any other tips?
> 
> For the record all I really want is a disc that is 100% totally
> encrypted no partition tables showing or anything.

You can use unpartitioned device /dev/hda and set up loop devices using
offset and sizelimit. If 'sfdisk -l -uS /dev/hda' says:

Units = sectors of 512 bytes, counting from 0
   Device Boot    Start       End  #sectors  Id  System
/dev/hda1   *        63     48194     48132  83  Linux
/dev/hda2         48195  11245499  11197305  83  Linux
/dev/hda3      11245500  12273659   1028160  82  Linux swap

And if you were to set up above three partitions as encrypted loop devices,
then you could issue these losetup commands:

losetup -e AES128 -K foo1.gpg -o  <at> 32256      -s 24643584   /dev/loop1 /dev/hda
losetup -e AES128 -K foo2.gpg -o  <at> 24675840   -s 5733020160 /dev/loop2 /dev/hda
(Continue reading)

Permalink | Reply | 13 comments |
headers
Gabriel Jägenstedt | 2 Apr 2005 00:17
Picon

Re: Partitions on loopback

Thanks for your help..

Could I just ask why you gave different keys for each device?

Oh and why is the first partition starting at sector 63?

On Fri, 01 Apr 2005 16:36:52 +0300
Jari Ruusu <jariruusu <at> users.sourceforge.net> wrote:

> Gabriel Jägenstedt wrote:
> > I've been spending several hours looking at ways to encrypt my
> > computer. I've read the Disc Encryption HOWTO and loop-aes readme
> > but can't find any information about how to partition up a loopback
> > device with partitions larger than 2GB. I have understood this
> > should be easier with kernel 2.6 but don't know anything more about
> > it.
> 
> loop-AES has supported 64 bit device offsets and sizelimits since
> November 29 2003. No 2GB limit on 2.4 or 2.6 kernels.
> 
> > Are there any comprehensive guides on partitioning a to be encrypted
> > loopback device (device backed)? Or does anyone have any other tips?
> > 
> > For the record all I really want is a disc that is 100% totally
> > encrypted no partition tables showing or anything.
> 
> You can use unpartitioned device /dev/hda and set up loop devices
> using offset and sizelimit. If 'sfdisk -l -uS /dev/hda' says:
> 
> Units = sectors of 512 bytes, counting from 0
(Continue reading)

Permalink | Reply | 12 comments |
headers
Rik van Riel | 2 Apr 2005 02:16
Favicon

Re: Somebody stop the junk mail!

On Wed, 30 Mar 2005, Hubert Chan wrote:

> Rik> Would it be acceptable to have a "self whitelisting" system here -
> Rik> ie. a "mailing list" that people can subscribe to, but not post to,
> Rik> and subscribers from that silent list would be allowed to post to
> Rik> the linux-crypto list ?
> 
> That would be fine with me.  I guess if nobody complains about this, we
> can go ahead with this.

OK, I've set up this list, trustedpost <at> nl.linux.org.  Note that
you can not send any email to this list - its only use is to
automatically be approved to send mail to any of the members-only
mailing lists on nl.linux.org.

You can subscribe like this:

$ echo subscribe | mail trustedpost-request <at> nl.linux.org

> Rik> Any volunteers ?
> 
> I wouldn't mind helping out.  Although I probably wouldn't be able to
> take it all on (e.g. I may be out of town at some points).
> 
> The amount of spam that actually does get through doesn't seem to be
> that much (and after we close the list, that should get rid of the guy
> who's using the list address to sign up for various things), so my guess
> is that this should only require a couple other people.

Indeed.  Lets see how the "trustedpost" thing works out, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Ruusu | 2 Apr 2005 11:00
Picon

Re: Partitions on loopback

Gabriel Jägenstedt wrote:
> Could I just ask why you gave different keys for each device?

Because that provides better protection against identical ciphertexts.
Identical ciphertexts using same encryption key are bad because they leak
information.

When sector data is encrypted or decrypted, position information within a
partition or device is used in IV computation and in multi-key mode to also
to select the encryption key. This provides reasonable guarantee that when
same data is written to more than one sectors, ciphertexts will be different
and attacker observing ciphertexts can't find out what plaintext sectors
contain identical data. If same key file is used to encrypt more than one
file system, there is a danger that same data + same encryption key + same
position info will result in identical ciphertexts.

Examples:
(A) losetup -e AES128 -K foo1.gpg /dev/loop1 /dev/hda1
(B) losetup -e AES128 -K foo2.gpg /dev/loop2 /dev/hda2
(C) losetup -e AES128 -K foo3.gpg /dev/loop3 /dev/hda3
(D) losetup -e AES128 -K foo1.gpg -o  <at> 32256      -s 24643584   /dev/loop1 /dev/hda
(E) losetup -e AES128 -K foo2.gpg -o  <at> 24675840   -s 5733020160 /dev/loop2 /dev/hda
(F) losetup -e AES128 -K foo3.gpg -o  <at> 5757696000 -s 526417920  /dev/loop3 /dev/hda
(G) losetup -e AES128 -K foo1.gpg -o 32256      -s 24643584   /dev/loop1 /dev/hda
(H) losetup -e AES128 -K foo2.gpg -o 24675840   -s 5733020160 /dev/loop2 /dev/hda
(I) losetup -e AES128 -K foo3.gpg -o 5757696000 -s 526417920  /dev/loop3 /dev/hda

In examples (A), (B), (C), (D), (E), and (F), first loop device sector is
encrypted using position info 0, second sector using position info 512,
third sector using position info 1024, and so on. In example (G) first loop
(Continue reading)

Permalink | Reply | 11 comments |
headers
Gabriel Jägenstedt | 2 Apr 2005 20:40
Picon

Re: Partitions on loopback

Ahh.. I see.

I was thinking in the lines of creating one big loopback device that
could then be "partitioned" using the offset and size parameters.
I think it would be quite nice if there could be no visible parts
outside the system. I have a feeling that creating loopback devices
directly from the hda would expose how big they are, which is not
desirable. Maybe this is true if you first encrypt the entire drive as
well.

losetup -e AES128 -K key.gpg -S <seed> -C 100 /dev/loop0 /dev/hda 
(Why does noone use AES256? Isn't that more secure? Is there a big speed
bump?)

losetup -o  <at> 32256-s 1003451904 /dev/loop1 /dev/loop0
losetup -o  <at> 1003484160 -s 1003451904 /dev/loop2/ /dev/loop0
losetup -o  <at> 2006936064 -s 5000937984 /dev/loop3/ /dev/loop0

I though something like the above. This might not be advisable though?

On Sat, 02 Apr 2005 12:00:56 +0300
Jari Ruusu <jariruusu <at> users.sourceforge.net> wrote:

> Gabriel Jägenstedt wrote:
> > Could I just ask why you gave different keys for each device?
> 
> Because that provides better protection against identical ciphertexts.
> Identical ciphertexts using same encryption key are bad because they
> leak information.
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Peter_22 | 3 Apr 2005 13:44
Picon
Picon

Re: Partitions on loopback

Hi!

I just saw what your talking about.
Well, to say it in short: If you do what Jari wrote, you will get what you
were asking for:-)
I was begging for the same some weeks ago. Using loop-aes there remains no
partition table or boot code on the harddrive. You have to start the PC from
usb-stick or cd-rom then.
Just do what Jari wrote, use the offsets to losetup. And calculate properly!

> I was thinking in the lines of creating one big loopback device that
> could then be "partitioned" using the offset and size parameters.

With regard to this, consider what your PC looks like when you installed a
Linux distro like SuSE or else. You have partitions. You must have them
because all distros will force you to set up some. So my proposal is you get
loop-aes and do what´s in the Readme. Example 7.7 is for you! When you
succeeded to boot your pc from USB-Stick then you can go on and remove the
mbr.
Big fat Warning:
Before erasing mbr like this:
dd if=/dev/zero of=/dev/hda bs=512 count=1
You have to *back up* the mbr to the usb-stick!!!!!!!
dd if=/dev/hda bs=512 count=1 >/media/usb/mbr.img
Removing mbr with partition table is extremely dangerous for all your data!
That´s why it is not mentioned in the loop-aes readme! Dont´ complain if you
loose the entire data in case you make a little mistake. The usb-stick is
all you have, there will be your partition table and your keys. Just in case
you want to upgrade to a new version of your distro (let´s say SuSE 9.3) you
will want your partition table back.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gabriel Jägenstedt | 3 Apr 2005 14:40
Picon

Re: Partitions on loopback

Great! 

I'll go with that version. Now I only have one problem.

I've already tried to set up encryption using 7.7 but even though my
running kernel has compiled in support for vfat I get an error message
telling me I don't. I've though of going with Disc Encryption HOWTO
instead and modify it to suit my needs. Jaris partioning and gpg keys
instead of the one in that document.

On Sun, 3 Apr 2005 13:44:47 +0200 (MEST)
Peter_22 <at> gmx.de wrote:

> Hi!
> 
> I just saw what your talking about.
> Well, to say it in short: If you do what Jari wrote, you will get what
> you were asking for:-)
> I was begging for the same some weeks ago. Using loop-aes there
> remains no partition table or boot code on the harddrive. You have to
> start the PC from usb-stick or cd-rom then.
> Just do what Jari wrote, use the offsets to losetup. And calculate
> properly!
> 
> > I was thinking in the lines of creating one big loopback device that
> > could then be "partitioned" using the offset and size parameters.
> 
> With regard to this, consider what your PC looks like when you
> installed a Linux distro like SuSE or else. You have partitions. You
> must have them because all distros will force you to set up some. So
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gabriel Jägenstedt | 3 Apr 2005 15:29
Picon

Re: Partitions on loopback

Another question.

> I have tested it for weeks. It works fine with AES256 as well. It´s
> only a matter of PC perfomance. You might also think about several
> layers of encryption. Two layers of 128 bit encryption should be safer
> than one layer with 256 bit as you can combine twofish, blowfish and
> aes on one partition.

Is it a simple thing to add an extra layer of encryption or so after
you've encrypted your drive? Or should this be planned for in advance? 

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/
Permalink | Reply | 1 comment |
headers
Jari Ruusu | 3 Apr 2005 18:19
Picon

Re: Partitions on loopback

Gabriel Jägenstedt wrote:
> I was thinking in the lines of creating one big loopback device that
> could then be "partitioned" using the offset and size parameters.

That would mean that all accesses would have to go through two loop devices,
which causes small overhead that can be avoided using what I suggested.

> I think it would be quite nice if there could be no visible parts
> outside the system. I have a feeling that creating loopback devices
> directly from the hda would expose how big they are, which is not
> desirable.

If you set up encrypted root using build-initrd.sh script from loop-AES
package and boot from USB-stick, then your hard disk will not have any info
where your partitions are and how big they are (Assuming that partition
table is erased).

The initrd boot from USB-stick will have plaintext info where and how big
your root partition is. Once you have booted to encrypted root, then init
scripts can set up the remaining encrypted "partitions" using losetup -o and
-s options. Init script reside on encrypted root so those offset+size infos
are not visible to attacker possessing "cold" disk.

Extra partition-table-less encrypted "partitions" can be automatically set
up like this in some init script that is run early in the boot process:

losetup -p 3 -e AES256 -o  <at> 32256    -s 24643584   /dev/loop1 /dev/hda 3</etc/fskey1.txt
losetup -p 3 -e AES256 -o  <at> 24675840 -s 5733020160 /dev/loop2 /dev/hda 3</etc/fskey2.txt

where /etc/fskey{1,2}.txt are text files containing 65 lines of random data,
(Continue reading)

Permalink | Reply | 5 comments |

Gmane