I am hoping someone could explain this:

When loop and cryptoloop are build into the kernel image, the features of
both products work fine -- i.e. I can mount encrypted file systems.

When these are compiled as modules, mount returns errors about wrong
filetypes.

My question is why? A lot of the documentation specifically refers to
using modprobe. I also observed the same when trying out dm-crypt and
loop-aes. They simply won't work as modules. I have util-linux 2.12q-r3
and use the old-crypt USE variable.

I have heard from another thread that some other "modules" also don't work
one way or the other. Alsa was noted as a problem for one poster who
claimed it would not work built in, but would work as modules.

Anyway, anyone who can help me understand the mechanics of what's going on
here will be appreciated

I understand the differences between loop-aes, dm-crypt and cryptoloop. I
stay with cryptoloop since right now, it's the only one that works for me.
Once I figure out how to get it to work as a module, that will be a step
in the right direction. Loop-aes replaced loop.ko and therefore can't be
built into the module AFAIK.

TIA

On Wed, 28 Sep 2005 11:52:22 -0400, Peter wrote:

> I am hoping someone could explain this:
>
> When loop and cryptoloop are build into the kernel image, the features of
> both products work fine -- i.e. I can mount encrypted file systems.
>
Followup: A combination I did not try was to leave loop built into the
kernel, and have cryptoloop, dm-crypt and dm-mod as modules. This
worked. Don't ask me why! Interesting that when I load cryptoloop, it
tries to load loop as a module, even though it's built in!

sudo modprobe cryptoloop
WARNING: Could not open '/lib/modules/2.6.12-gentoo-r10/block/loop.ko': No such file or directory

But, it works, and so does dm-crypt.

So now, at last, I can retire cryptoloop and move to dm-crypt.

HTH

I use loop-aes on my gentoo system, but I did not get it from portage.
If you get the sources, and build it using the build-init.sh script
included, and it builds loop.ko as a module which worked for me.

You have to set up a /boot partition and put a bunch of static-linked
programs in it, as well as patch and rebuild the util-linux package
(things like mount, modprobe, umount, losetup) and use gpg key.

I use the vanilla-sources 2.6.12.5 kernel package and use loop-aes as a
module, with cryptoloop support not compiled in.

I have not tried cyptoloop and although I am not a crypto expert, I have
heard it is vulnerable to an attack technique known as watermarking, so
I do not use it. My view is that if you are going to go to the trouble
to encrypt a drive in the first place, you may as well use the best that
exists, which I've heard is either truecrypt or loop-aes, depending on
who you talk to.

~David~

PS - I'm also paranoid enough (anyone who actually encrypts their
personal computers drive has to be at least somewhat techie and
paranoid, right?) that I would not put it past NSA and the US government
to have fast and working methods that crack ciphers which are "in the
wild" like AES and BlowFish.

Peter wrote:
> On Wed, 28 Sep 2005 11:52:22 -0400, Peter wrote:
>
>
>>I am hoping someone could explain this:
>>
>>When loop and cryptoloop are build into the kernel image, the features of
>>both products work fine -- i.e. I can mount encrypted file systems.
>>
>
> Followup: A combination I did not try was to leave loop built into the
> kernel, and have cryptoloop, dm-crypt and dm-mod as modules. This
> worked. Don't ask me why! Interesting that when I load cryptoloop, it
> tries to load loop as a module, even though it's built in!
>
> sudo modprobe cryptoloop
> WARNING: Could not open '/lib/modules/2.6.12-gentoo-r10/block/loop.ko': No such file or directory
>
> But, it works, and so does dm-crypt.
>
> So now, at last, I can retire cryptoloop and move to dm-crypt.
>
> HTH

David <shadoweyez@hotpop.com> writes:


>PS - I'm also paranoid enough (anyone who actually encrypts their
>personal computers drive has to be at least somewhat techie and
>paranoid, right?) that I would not put it past NSA and the US government
>to have fast and working methods that crack ciphers which are "in the
>wild" like AES and BlowFish.

No need. They can read your mind and extract the key directly from it. No
need to break the cypher.

On Fri, 30 Sep 2005 05:23:16 +0000, Unruh wrote:

> David <shadoweyez@hotpop.com> writes:
>
>
>>PS - I'm also paranoid enough (anyone who actually encrypts their
>>personal computers drive has to be at least somewhat techie and
>>paranoid, right?) that I would not put it past NSA and the US government
>>to have fast and working methods that crack ciphers which are "in the
>>wild" like AES and BlowFish.
>
> No need. They can read your mind and extract the key directly from it. No
> need to break the cypher.

LOL at that! I thought it was in the water though. Seriously, in my case,
the encrypted files are not even in fstab, hence they are manually mounted
sometime after boot on demand. Many of the examples given just assumed you
are booting the mount. That's actually not so good since why leave the
encrypted device open?

But this was a tough one for me to debug. In my case, loop was built in.
Now, at least I got dm-crypt to work. Next, I can bang my head against the
wall and see about loop being a module, although that really is
unimportant.

David <shadoweyez@hotpop.com> wrote:
> I use loop-aes on my gentoo system, but I did not get it from portage.
> If you get the sources, and build it using the build-init.sh script
> included, and it builds loop.ko as a module which worked for me.

Many of us prefer a monolithic kernel, as it's leaner and meaner. The
moment you add module *support* -- not even a module, the kernel has to
use tables for looking up functions.
Any app that /assumes/ it's a module is IMO broken and should be
avoided -- at least I wouldn't trust *security* related stuff to people
who make assumptions like that.

Regards,
--
*Art

Unruh <unruh-spam@physics.ubc.ca> wrote:
> David <shadoweyez@hotpop.com> writes:
>
>
>> PS - I'm also paranoid enough (anyone who actually encrypts their
>> personal computers drive has to be at least somewhat techie and
>> paranoid, right?) that I would not put it past NSA and the US
>> government to have fast and working methods that crack ciphers which
>> are "in the wild" like AES and BlowFish.
>
> No need. They can read your mind and extract the key directly from
> it. No need to break the cypher.

This is unfortunately more true than you probably intended it to be, at
least here in the US. Here, you are /required/ to provide any
cryptographic keys to law enforcement agencies, despite there being a
fifth amendment to the constitution giving you the right not to
incriminate yourself. Three weeks with a room mate named Bubba and the
promise of twelve more years unless you cough any codes up would be
enough to extract the keys from almost anyone.

In Minnesota, the mere presence of crypto software is admissable as
evidence of intent to break the law.

Regards,
--
*Art

"Arthur Hagen" <art@broomstick.com> writes:

>Unruh <unruh-spam@physics.ubc.ca> wrote:
>> David <shadoweyez@hotpop.com> writes:
>>
>>
>>> PS - I'm also paranoid enough (anyone who actually encrypts their
>>> personal computers drive has to be at least somewhat techie and
>>> paranoid, right?) that I would not put it past NSA and the US
>>> government to have fast and working methods that crack ciphers which
>>> are "in the wild" like AES and BlowFish.
>>
>> No need. They can read your mind and extract the key directly from
>> it. No need to break the cypher.

>This is unfortunately more true than you probably intended it to be, at
>least here in the US. Here, you are /required/ to provide any
>cryptographic keys to law enforcement agencies, despite there being a
>fifth amendment to the constitution giving you the right not to
>incriminate yourself. Three weeks with a room mate named Bubba and the

Apparently "here" making up laws by the populace means no laws ever have to
actually be passed. Your contention is AFAIK without any basis in fact. You
are NOT required to provide keys. Or perhaps you could provide the court
ruling or the law which /requires/ it.

>promise of twelve more years unless you cough any codes up would be
>enough to extract the keys from almost anyone.

>In Minnesota, the mere presence of crypto software is admissable as
>evidence of intent to break the law.

While certainly a very weird ruling, it says nothing about your earlier
contention. That case had nothing to do with keys.

Unruh <unruh-spam@physics.ubc.ca> wrote:
> "Arthur Hagen" <art@broomstick.com> writes:
>
>> Unruh <unruh-spam@physics.ubc.ca> wrote:
>>>
>>> No need. They can read your mind and extract the key directly from
>>> it. No need to break the cypher.
>
>> This is unfortunately more true than you probably intended it to be,
>> at least here in the US. Here, you are /required/ to provide any
>> cryptographic keys to law enforcement agencies, despite there being a
>> fifth amendment to the constitution giving you the right not to
>> incriminate yourself. Three weeks with a room mate named Bubba and
>> the
>
> Apparently "here" making up laws by the populace means no laws ever
> have to actually be passed. Your contention is AFAIK without any
> basis in fact. You are NOT required to provide keys. Or perhaps you
> could provide the court ruling or the law which /requires/ it.

U.S.C. 18, chapter 121, section 2703 as amended by the USA Patriot Act,
among others. You have to cough up the *records*, not just the
encrypted data, and unless they let you access the machine in privacy,
that means forking over any keys.

(Also note that Patriot II would make it a crime to use encryption as
part of another crime, as well as broadening the scope from suspected
terrorism-related activities to /any/ federal crime. Yes, this is in
parentheses.)

--
*Art

From a security standpoint, having modules in a kernel is not inherently
a bad thing. With things like loop-aes, even if your adversary gets
hold of your system/hard drive and its not turned on, the data is still
well encrypted, regardless if the method used to encrypt the data
involved a kernel module or not.

That said, I prefer a monolithic kernel and usually compile everything
in as much as possible, but some of my hardware requires modules to run,
and loop-aes is compiled and setup as a module as well. But my
preference has nothing to do with security; it's more of a
cleanliness/performance/memory saving/stability thing.

Aside from all the thrill sci-fi (they can read your mind!!!) and
government paranoia (no password/key=gun to your head or prison time)
the goal of all encryption is to stop people from getting to your data
at a TECHNICAL level, not a legal or human-threat level. Leave that to
lawyers and cool movie-like assassins.


In the real world, its much less cooler than movies. I read of a study
that said most people would trade their work password for a candy bar.
I know I would ;-)
(JK!)

Arthur Hagen wrote:
> David <shadoweyez@hotpop.com> wrote:
>
>>I use loop-aes on my gentoo system, but I did not get it from portage.
>>If you get the sources, and build it using the build-init.sh script
>>included, and it builds loop.ko as a module which worked for me.
>
>
> Many of us prefer a monolithic kernel, as it's leaner and meaner. The
> moment you add module *support* -- not even a module, the kernel has to
> use tables for looking up functions.
> Any app that /assumes/ it's a module is IMO broken and should be
> avoided -- at least I wouldn't trust *security* related stuff to people
> who make assumptions like that.
>
> Regards,