Been away from the list for awhile and you went
and moved the list on me!
Yesterday I pulled out my notes from the last time
I set up a crypto disk and found that basically,
nothing worked.
The losetup lists all the appropriate crypto types
in its Man page but when I try to actually use AES256,
it throws a fit. When I look in modules for the
current kernel, I do not see a module for aes at all.
I might also note that I was surprised to find the -k
switch for specifying key size is gone.
I tried downloading a package with aes in it, but it
turns out to require local build. So... I tried that.
I discovered that the module failed to declare kpkg
as a prerequisite. I eventually figured that error out
and selected it manually.
And then I tried everything I could think of short of
going 'all the way in': I tried module-assistant; I
tried m-a; I tried the commands from the INSTALL file
one at a time. All of them failed.
This is just SOOooo 1999... aren't things supposed to
get better with time? ;-)
I would be happy to supply any information required
or to run a few tests in between other work. Test
server is an ancient (perhaps 2003) box with Ubuntu
Oneiric, fully up to date.
If I want to use something like this for a production
environment, it has to be solid and update and work
forever into the future.
Hey there Dale & List,
I believe Ryan and Bill (CC'd) are using AES full disk crypto on their
systems. It seems complicated to me, but they can probably give you
tips. I think Bill is using Debian and Ryan is using Arch. Bill's
(DISA's) policies are pretty strict and probably require that his smart
card be inserted at boot time. Ryan's history administering the
intranet for a company in the medical field have set his bar probably
higher than DISA's in many ways, but may not require that the physical
token be inserted at boot.
Cheers && 73,
C.J.
On Wed, 2012-03-28 at 13:17 +0100, Dale Amon wrote:
> Been away from the list for awhile and you went
> and moved the list on me!
>
> Yesterday I pulled out my notes from the last time
> I set up a crypto disk and found that basically,
> nothing worked.
>
> The losetup lists all the appropriate crypto types
> in its Man page but when I try to actually use AES256,
> it throws a fit. When I look in modules for the
> current kernel, I do not see a module for aes at all.
>
> I might also note that I was surprised to find the -k
> switch for specifying key size is gone.
>
> I tried downloading a package with aes in it, but it
> turns out to require local build. So... I tried that.
>
> I discovered that the module failed to declare kpkg
> as a prerequisite. I eventually figured that error out
> and selected it manually.
>
> And then I tried everything I could think of short of
> going 'all the way in': I tried module-assistant; I
> tried m-a; I tried the commands from the INSTALL file
> one at a time. All of them failed.
>
> This is just SOOooo 1999... aren't things supposed to
> get better with time? ;-)
>
> I would be happy to supply any information required
> or to run a few tests in between other work. Test
> server is an ancient (perhaps 2003) box with Ubuntu
> Oneiric, fully up to date.
>
> If I want to use something like this for a production
> environment, it has to be solid and update and work
> forever into the future.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Classification: UNCLASSIFIED
I've used AES before. Came on a disk, popped it in, self started and asked me to supply a password (initial setup stuff), about 3 hours later I had an encryped hard disk. This was for my corp laptop though, I don't use it on my home Debian laptop. My current work desktop had encryption also that uses the CAC cert to encrypt. I don't know the name though as it is all managed from the ivory tower folks in the IT shop. It works well from the user standpoint right up to the point where your CAC cert expires. You then get a take your new CAC and a live chicken to our provisioners. There is a blood sacrifice and some internet wizard stuff that goes on then a guy/gal has to touch your desktop and type in the "magic text" in the (horror of horrors) command prompt (Yes martha it is winders vista). About an hour later your disk is encrypted with the new cert.
What is the situation that is calling for a "data at rest" encryption solution?
Bill
SOF Imperative #8 Apply capabilities indirectly
William Roosa
MAJ, SF
703-268-8311 (cell)
703-545-1509 (w)
[email protected]
De Oppreso Liber
ﺗﺤﺭﻴﺮ ﺁﻞ مضطهدﻴﻦ
On 03/28/12, "C.J. Adams-Collier KF7BMP" <[email protected]> wrote:
> Hey there Dale & List,
>
> I believe Ryan and Bill (CC'd) are using AES full disk crypto on their
> systems. It seems complicated to me, but they can probably give you
> tips. I think Bill is using Debian and Ryan is using Arch. Bill's
> (DISA's) policies are pretty strict and probably require that his smart
> card be inserted at boot time. Ryan's history administering the
> intranet for a company in the medical field have set his bar probably
> higher than DISA's in many ways, but may not require that the physical
> token be inserted at boot.
>
> Cheers && 73,
>
> C.J.
>
> On Wed, 2012-03-28 at 13:17 +0100, Dale Amon wrote:
> > Been away from the list for awhile and you went
> > and moved the list on me!
> >
> > Yesterday I pulled out my notes from the last time
> > I set up a crypto disk and found that basically,
> > nothing worked.
> >
> > The losetup lists all the appropriate crypto types
> > in its Man page but when I try to actually use AES256,
> > it throws a fit. When I look in modules for the
> > current kernel, I do not see a module for aes at all.
> >
> > I might also note that I was surprised to find the -k
> > switch for specifying key size is gone.
> >
> > I tried downloading a package with aes in it, but it
> > turns out to require local build. So... I tried that.
> >
> > I discovered that the module failed to declare kpkg
> > as a prerequisite. I eventually figured that error out
> > and selected it manually.
> >
> > And then I tried everything I could think of short of
> > going 'all the way in': I tried module-assistant; I
> > tried m-a; I tried the commands from the INSTALL file
> > one at a time. All of them failed.
> >
> > This is just SOOooo 1999... aren't things supposed to
> > get better with time? ;-)
> >
> > I would be happy to supply any information required
> > or to run a few tests in between other work. Test
> > server is an ancient (perhaps 2003) box with Ubuntu
> > Oneiric, fully up to date.
> >
> > If I want to use something like this for a production
> > environment, it has to be solid and update and work
> > forever into the future.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Classification: UNCLASSIFIED
On Wed, Mar 28, 2012 at 09:37:16AM -0700, C.J. Adams-Collier KF7BMP wrote:
| card be inserted at boot time. Ryan's history administering the
| intranet for a company in the medical field have set his bar probably
| higher than DISA's in many ways, but may not require that the physical
| token be inserted at boot.
It really depends on which machine it is. The nice thing about LUKS is that
you can define multiple keys per encrypted volume. In the case of one of my
headless machine, I have two defined: one passphrase I physically type in and
a giant on that is on a USB key (in the event I need to reboot the machine but
don't want to have to find a monitor and keyboard).
Full disk encryption with LUKS is actually pretty easy, and I do have the full
process written down. I've been looking for a reason to actually type it out
for later use...I'll do that later today and then send it on for reference.
later.
ryanc
--
http://pgp.mit.edu:11371/pks/lookup?search=ryanc%40greengrey.org
On Wed, Mar 28, 2012 at 12:03:22PM -0700, Ryan Corder wrote:
> Full disk encryption with LUKS is actually pretty easy, and I do have the full
> process written down. I've been looking for a reason to actually type it out
> for later use...I'll do that later today and then send it on for reference.
Nothing so complicated... I've been through this
at the arcane level a decade ago. What I was looking for
was the status of doing the following:
apt-get install <listofpackages>
dd if=/dev/zero of=mynew.ext4 count=30G
losetup -e aes256 /dev/loop0 mynew.ext
password: <type in the magic phrase>
go out for coffee
mkfs.ext4 /dev/loop0 -m 0.0 -L "WhoIsJohnGalt"
mount -t ext4 /dev/loop0 /mnt
The kernel is an out of the box Ubuntu 3.0.0-17-generic-pae.
The losetup man page on Ubuntu host shows:
-e encryption
Enable data encryption. Following encryption types are recognized:
NONE Use no encryption (default).
XOR Use a simple XOR encryption.
AES128 AES
Use 128 bit AES encryption. Passphrase is hashed with
SHA-256 by default.
AES192 Use 192 bit AES encryption. Passphrase is hashed
with SHA-384 by default.
AES256 Use 256 bit AES encryption. Passphrase is hashed
with SHA-512 by default.
twofish128 twofish160 twofish192 twofish256
blowfish128 blowfish160 blowfish192 blowfish256
serpent128 serpent192 serpent256 mars128 mars192
mars256 rc6-128 rc6-192 rc6-256 tripleDES
These encryption types are available if they are
enabled in kernel configuration or corresponding
modules have been loaded to kernel.
However if you look in
/lib/modules/3.0.0-17-generic-pae/kernel/crypto/
there seems to be everything under the sun except AES.
Now it used to be the case that AES was pretty much the default.
I know Jaari pushed it really hard. In any case, I found a
package to load:
*** Opt universe loop-aes-sou 3.3a-2 3.3a-2 source for loop-AES encryption modules
*** Opt universe loop-aes-tes 3.3a-2 3.3a-2 test suite for loop-AES encryption modules
*** Opt universe loop-aes-uti 2.16.2-2ubu 2.16.2-2ubu Tools for mounting and manipulating filesystems
I duly installed them. This put a do it yourself package
into /usr/src/:
loop-aes.tar.bz2
Now, reading
/usr/share/doc/loop-aes-source/README.Debian
I see the following options:
Quick start
-----------
$ apt-get install loop-aes-utils
for Debian kernels
$ m-a auto-install loop-aes
for custom kernels
$ cd /usr/src
$ tar -xjf loop-aes.tar.bz2
$ cd /path/to/kernel
$ make-kpkg modules_image
$ dpkg -i /usr/src/loop-aes*.deb
Building loop-AES with module-assistant
---------------------------------------
module-assistant makes it very easy to build loop-AES packages
for both Debian kernels and custom kernels. It is also the
recommended way to build loop-AES on Debian systems.
The below command builds and installs a loop-AES module package
for the currently running kernel:
# module-assistant auto-install loop-aes
So, using that command while sitting in /usr/src:
module-assistant auto-install loop-aes
It runs for awhile
# module-assistant auto-install loop-aes
Updated infos about 1 packages
Getting source for kernel version: 3.0.0-17-generic-pae
apt-get install linux-headers-3.0.0-17-generic-pae
Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-headers-3.0.0-17-generic-pae is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
apt-get install build-essential
Reading package lists... Done
Building dependency tree
Reading state information... Done
build-essential is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
And then gives me three different panels to read:
Bad luck, the kernel headers for the target kernel version could
not be found and you did not specify other valid kernel headers
to use.
However, you can install the header files for your kernel which
are provided by the linux-headers-3.0.0-17-generic-pae package.
For most modules packages, these files are perfectly sufficient
without having the original kernel source.
To install the package, run the PREPARE command from the main
menu, or on the command line:
module-assistant prepare
Package loop-aes-source was not built successfully, see
/var/cache/modass/loop-aes-source*buildlog* for details!
and that log has the following relevant text:
make[3]: Entering directory `/KdevRoot/src/linux-headers-3.0.0-17-generic-pae'
make[4]: *** No rule to make target `/KdevRoot/src/modules/loop-aes/tmp-d-kbuild/patched-loop.c', needed by `/KdevRoot/src/modules/loop-aes/tmp-d-kbuild/patched-loop.o'. Stop.
So does anyone have a suggestion as to where I have
gone wrong? It's been over half a decade since I've
gone through this and even longer since I was doing
the magic dance with patching and building my own
losetup, mount, etc...
On 03/28/2012 10:42 PM, Dale Amon wrote:
> So does anyone have a suggestion as to where I have
> gone wrong? It's been over half a decade since I've
> gone through this and even longer since I was doing
> the magic dance with patching and building my own
> losetup, mount, etc...
If you want something simple, use LUKS. cryptsetup
and dmcrypt is in all distributions by default.
Truecrypt uses dmcrypt by default as backend as well.
Of course, if you want use loop-aes, you have to
patch all utilities and kernel, it is not so complicated.
(cryptsetup can run loop-aes compatible mode as well and
can allocate loop device as well. But it is your
choice what encryption and utility to use to use
of course.)
For default losetup from util-linux, encryption option
is in fact deprecated in favor to cryptsetup.
Milan
On Wed, Mar 28, 2012 at 11:14:41PM +0200, Milan Broz wrote:
> If you want something simple, use LUKS. cryptsetup
> and dmcrypt is in all distributions by default.
> Truecrypt uses dmcrypt by default as backend as well.
Looking around a bit, it appears that cryptsetup is in
the ubuntu server set up disk.
> Of course, if you want use loop-aes, you have to
> patch all utilities and kernel, it is not so complicated.
I'm not wedded to it... as I noted I have been out of
the loop, crypt or otherwise, for half a decade.
> (cryptsetup can run loop-aes compatible mode as well and
> can allocate loop device as well. But it is your
> choice what encryption and utility to use to use
> of course.)
>
> For default losetup from util-linux, encryption option
> is in fact deprecated in favor to cryptsetup.
Okay. Now do cryptsetup and the others work in a pretty
standard way? ie, put them in your /etc/fstab and
just feed them a password when you want to mount? Or if
it is a loopback image, you just do the usual
mount -o loop file /mnt
?
Classification: UNCLASSIFIED
Seems to hang when it can't find the kernel headers.
If you forget that they can come with the package for a moment and just install them directly. If you've been away for some time you probably did not get the memo that systems don't come with the headers or kernel source code by default so you have to go get that package.......
Such is the brave new world where things are done for us by others.
Bill
William Roosa
MAJ, SF
703-268-8311 (cell)
703-545-1509 (w)
[email protected]
De Oppreso Liber
ﺗﺤﺭﻴﺮ ﺁﻞ مضطهدﻴﻦ
On 03/28/12, Dale Amon <[email protected]> wrote:
> On Wed, Mar 28, 2012 at 11:14:41PM +0200, Milan Broz wrote:
> > If you want something simple, use LUKS. cryptsetup
> > and dmcrypt is in all distributions by default.
> > Truecrypt uses dmcrypt by default as backend as well.
>
> Looking around a bit, it appears that cryptsetup is in
> the ubuntu server set up disk.
>
> > Of course, if you want use loop-aes, you have to
> > patch all utilities and kernel, it is not so complicated.
>
> I'm not wedded to it... as I noted I have been out of
> the loop, crypt or otherwise, for half a decade.
>
> > (cryptsetup can run loop-aes compatible mode as well and
> > can allocate loop device as well. But it is your
> > choice what encryption and utility to use to use
> > of course.)
> >
> > For default losetup from util-linux, encryption option
> > is in fact deprecated in favor to cryptsetup.
>
> Okay. Now do cryptsetup and the others work in a pretty
> standard way? ie, put them in your /etc/fstab and
> just feed them a password when you want to mount? Or if
> it is a loopback image, you just do the usual
>
> mount -o loop file /mnt
>
> ?
--
Classification: UNCLASSIFIED
Just thought it might be useful for someone else
in the future if I feed back the results of some
of my tests.
The first test is the set up of a dm-crypt based
loop back partition:
# Create a file for our little 30GB test disk
dd if=/dev/zero of=other.ext4 count=60M
# Connect it as a loop back.
losetup /dev/loop0 other.ext4
# Do a badblocks check that leaves random data on
# the 'underlying' media.
badblocks -c 10240 -s -w -t random -v /dev/loop0
# Generate the partition table and create a single
# partition
cfdisk /dev/loop0
# We will need kpartx to make the partition accessible
apt-get install kpartx
kpartx -a -v /dev/loop0
ls -alF /dev/mapper
# Now make it a crypt partition and give it a password
cryptsetup --verbose --verify-passphrase luksFormat /dev/mapper/loop0p1
WARNING!
========
This will overwrite data on /dev/mapper/loop0p1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
# Do the partition crypto set up and give it a device name:
cryptsetup luksOpen /dev/mapper/loop0p1 junk1
Enter passphrase for /dev/mapper/loop0p1:
# Now put a file system on it, create a mount point and
# mount it.
mkfs.ext4 /dev/mapper/junk1 -m 0.0 -L "WhoIsJohnGalt"
mkdir /junk1
mount /dev/mapper/junk1 /junk1
The remaining puzzle bits here are the issue of how to make
this work off of /etc/fstab, if that is possible. I also am
going to see if the resulting file backed crypto disk is
directly mountable on a VM as well.
In addition, I still also want to take a look at what it takes
to make loop-aes work. I was more involved with the cryptoloop
guys way back when and AFAIK, it's dead and gone.
Any suggestions about the fstab issues are welcome.