# FS encryption - which one to use?

## bastibasti

Hi there, 

I was wondering about encrypting one of my partitions and looking through the web.. AS I dont use windows STEGANOS is not the right choice  :Smile: 

Which is the best (unhackable) solution for linux?

----------

## ToeiRei

first of all - nothing is 'unhackable'. Sorry for breaking your dreams, but that's a fact.

[/profile]All you can do is making it _very_ difficult to crack it. Depending on what you're planing to encrypt there are various ways to do that.

Rei

----------

## bastibasti

okay.   :Wink: 

I have a USB harddrive and I want to encrypt the content on it (in case it gets lost) I have read somewhere that some encryption methods are easier to hack, but some would take too long...

----------

## neuron

I'd use aes256, with a ssl key.  Aes256... won't be broken by anyone that'd be remotely interested in your usb drive, neither will the ssl key.  But keep in mind brute forcing, your password is most likely the weak point.

----------

## boerKrelis

 *Quote:*   

> first of all - nothing is 'unhackable'. Sorry for breaking your dreams, but that's a fact. 

 

No it isn't. That's folklore. http://en.wikipedia.org/wiki/One-time_pad  One-Time pad is unbreakable.

I use encfs on some occasions. From the looks of it, I'm tempted to recommend the new ecryptfs in the kernel:

http://ecryptfs.sourceforge.net/ Homepage

http://www.linuxjournal.com/article/9400 Linuxjournal article

Symbol: ECRYPT_FS

Prompt: eCrypt filesystem layer support (EXPERIMENTAL)

Depends on: EXPERIMENTAL && KEYS && CRYPTO && NET

-> File systems -> Miscellaneous filesystems

----------

## ToeiRei

well... they said the same thing for other encryption methods until someone found a way round them...

Rei

----------

## pdr

I use cryptsetup with luks for my encrypted partitions; the big benefit with luks is that you can change the key (internally there is a generated key that is actually used for encrypt/decrypt; your replaceable key(s) are used to gain access to the generated one). My partitions do not autoload; in order to access one I have a small bash script called msecret that prompts for passphrase (I use a passphrase; you could use a usb key instead) and mounts them; I have another called usecret that umounts/unmaps them. I say "them" because I have multiple encrypted partitions. So, for example, when I want to access the "misc" partition and mount it to /media/misc, as root I run:

```
msecret misc

<prompted for passphrase>

<fsck checks the /media/misc partition>

I can now access the /media/misc partition
```

When I am done using it, I run - again as root:

```
usecret misc
```

This works because my device mapper name is the same as the name under /media/ for the mount point; also the partition (actually an LVM2 volume) has the same name. msecret script looks like:

```
#!/bin/sh

if [ -z "$1" ]; then

    echo "You must pass in which mapper device to mount!"

    exit 2

fi

cryptsetup luksOpen "/dev/vg/$1" "$1"

fsck -C "/dev/mapper/$1"

mount "/media/$1"
```

So for "msecret misc" it does:

```
cryptsetup luksOpen "/dev/vg/misc" "misc" # where /dev/vg/misc is the logical volume in LVM2 - you would want /dev/xxx - wherever your usb drive is set by udev

# It maps it to /dev/mapper/misc - ie the same name

fsck -C "/dev/mapper/misc"  # run fsck on the newly mapped device

mount "/media/misc"  # in fstab I have an entry to mount /dev/mapper/misc to /media/misc
```

usecret is easy and looks like:

```
#!/bin/sh

if [ -z "$1" ]; then

    echo "You must provide the name of the encrypted volume!"

    exit 2

fi

umount "/media/$1" && cryptsetup luksClose "$1"
```

So you could add a udev rull that would, say, map your external usb drive to "/dev/extusb". If you make a mount point (and put it in fstab) that mounts /dev/mapper/extusb to, say, /mnt/extusb then you could use those scripts:

```
msecret extusb # to mount it to /mnt/extusb

...

usecret extusb  # to unmount it
```

As far as how to set up cryptsetup and luks on a drive, I think i got that from gentoo-wiki (or in the forums here)..

----------

## guero61

 *ToeiRei wrote:*   

> well... they said the same thing for other encryption methods until someone found a way round them...
> 
> Rei

 

Certainly, but OTP is the nearly unachievable encryption goal every other method attempts to approximate.  It is mathematically provable that mistake-free OTP (truly random, only ever used once) is 'unbreakable' beyond brute-force attacks, which is all any encryption can hope for.  Every other cipher attempts to resemble the output of OTP (seemingly random bits), just with less original key material.  In other words, AES-128 uses 128 bits of key material to encrypt arbitrary amounts of data and achieves perceived randomness by mangling the key in a repeatable manner (key scheduling algorithm); OTP uses N bits of [random] key material to encrypt N bits of data.  No key schedule == no weakness.

http://en.wikipedia.org/wiki/One-time_pad

That said, if you're doing full-disk encryption, use dm-crypt or loop-aes.  Loop-aes has been argued as more secure than dm-crypt, but if you can guarantee an attacker won't see you write data (i.e. across a network link or with your drive cables compromised), dm-crypt is sufficient for most purposes and has tighter integration with already-existing kernel facilities.  I use a modified version of http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS to boot from a CD with a PGP-armored key.  Nothing plaintext is left on the drive, and the boot media is more easily secured/checksummed/audited.

If you just want a container for a bunch of files, Truecrypt has decent cross-platform capabilities.  I use it when I have to.

----------

## Sachankara

I use luks on my laptop and my external USB harddisk. It's really easy to use, and if you're using gnome-volume-manager you can plug in a luks device and a prompt will ask you for a password. No need to open a terminal to mount luks devices with a decent volume manager.  :Smile: 

On my laptop I have two partitions: One boot partition which isn't encrypted and then another one using luks. I also run LVM2 over the luks partition so I can create resizeable dynamic partitions. Because luks extends over almost the entire disk, everything from the root file system to the swap is encrypted with just a single password. A good tip is to use genkernel to manage the booting, luks password prompt, lvm2 initialization, etc.  :Smile: 

----------

## nielchiano

 *boerKrelis wrote:*   

>  *Quote:*   first of all - nothing is 'unhackable'. Sorry for breaking your dreams, but that's a fact.  
> 
> No it isn't. That's folklore. http://en.wikipedia.org/wiki/One-time_pad  One-Time pad is unbreakable.
> 
> 

 

true, but useless

your one-time-pad "password" would be as long as the data itself; so you could just as well memorize that data instead. Encryption is generally used to convert large secrets (your data) into smaller ones (the key/password/...); one-time-pads don't do this

----------

## lghman

 *guero61 wrote:*   

> 
> 
> That said, if you're doing full-disk encryption, use dm-crypt or loop-aes.  Loop-aes has been argued as more secure than dm-crypt, but if you can guarantee an attacker won't see you write data (i.e. across a network link or with your drive cables compromised), dm-crypt is sufficient for most purposes and has tighter integration with already-existing kernel facilities.  I use a modified version of http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS to boot from a CD with a PGP-armored key.  Nothing plaintext is left on the drive, and the boot media is more easily secured/checksummed/audited.
> 
> If you just want a container for a bunch of files, Truecrypt has decent cross-platform capabilities.  I use it when I have to.

 

1) How would writing data across a network link compromise your encryption?  Is is possible to compare that data to somewhere on a drive and hash a key out of it?

2) Do you have any specific links where people argue that Loop-aes is more secure?

I remember doing a loop-aes encrytion in the past, and it wasn't all that bad.  I just thought that dm-crypt was the standerd now and that loop-aes was obsolete, but if that is not the case I will do loop-aes again.

----------

## nielchiano

 *sonikntails wrote:*   

> 1) How would writing data across a network link compromise your encryption?  Is is possible to compare that data to somewhere on a drive and hash a key out of it?

 

I'm not sure if this applies to Loop-AES; but I know the mode you use your cipher in may allow data-leaks. Since dm-crypt can only do CBC and not LRW, modification patterns are not hidden.

http://clemens.endorphin.org/LinuxHDEncSettings provides a good overview of that.

----------

## Dralnu

I'm just asking because I'm curious:

Does someone have a good howto on doing any of this? Its something I've been thinking of trying out...

Also, are their any good ways to pass around encrypted data on a network, encrypting the traffic itself.

----------

## lghman

 *Dralnu wrote:*   

> I'm just asking because I'm curious:
> 
> Does someone have a good howto on doing any of this? Its something I've been thinking of trying out...
> 
> 

 

I am going to follow the same guide I used when I did it a few years ago, which is this one by chadders:

https://forums.gentoo.org/viewtopic-t-31363-highlight-loopaes.html

Towards the end someone mentions that you should read the loop-aes readme, so I will do that also.

 *Dralnu wrote:*   

> 
> 
> Also, are their any good ways to pass around encrypted data on a network, encrypting the traffic itself.

 

You can use tunnels, like simple ssh tunnels or more complicated VPN's.  I actually use a VPN setup on my wireless network to protect the network and the data.

----------

## madisonicus

Yeah, a VPN is excellent for data transfer over a network, especially when done with individual PKI certs.  But, it's often overkill for most folks.  Tunneling traffic over SSH is incredibly easy, and very secure if set up properly.

Here's a quick and dirty guide for setting up firefox to use an SSH tunnel: long link.

@nielchiano: Thanks for that link.  Some great info there.  Am I correct in interpreting the "inflexion point" as being the point at which an IV is likely to repeat, causing the potential data leak?  Because, at 146 million TB--a little bit bigger than my HDD--CBC still seems pretty secure.

I see that dmcrypt via cryptsetup-LUKS and Truecrypt support AES in LRW mode.  It doesn't look like OpenSSL  supports LRW though.  Are there other projects out there that are implementing LRW?

-m

----------

## nielchiano

 *madisonicus wrote:*   

> I see that dmcrypt via cryptsetup-LUKS and Truecrypt support AES in LRW mode.  It doesn't look like OpenSSL  supports LRW though.  Are there other projects out there that are implementing LRW?

 

Hmm... (emph mine) *http://clemens.endorphin.org/aboutme wrote:*   

> Among my minor contributions is a port of the 586/686 assembler version of AES to the Linux kernel. I invented and implemented ESSIV for dm-crypt. The first industry-ready implementation of LRW  an encryption mode far superior to the established CBC  has also been penned by me. Unfortunately, the last contribution never made its way into upstream kernels, as the kernel core developers neglected to make necessary clean-ups to their in-kernel memory management.

 

looks like LRW doesn't work with dm-crypt then?

About that inflexion point: don't know  :Wink: 

----------

## lagalopex

I think lrw is working fine: LRW now in 2.6.20, supported by cryptsetup-luks?

So, its the way to go   :Wink: 

----------

## lghman

 *lagalopex wrote:*   

> I think lrw is working fine: LRW now in 2.6.20, supported by cryptsetup-luks?
> 
> So, its the way to go  

 

Glad I haven't gotten around to this yet.  I guess I will follow that guide instead.

----------

## kernelOfTruth

 *Dralnu wrote:*   

> I'm just asking because I'm curious:
> 
> Does someone have a good howto on doing any of this? Its something I've been thinking of trying out...
> 
> Also, are their any good ways to pass around encrypted data on a network, encrypting the traffic itself.

 

http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian

http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS

trying this out right now ...

----------

## Roman_Gruber

 *kernelOfTruth wrote:*   

>  *Dralnu wrote:*   I'm just asking because I'm curious:
> 
> Does someone have a good howto on doing any of this? Its something I've been thinking of trying out...
> 
> Also, are their any good ways to pass around encrypted data on a network, encrypting the traffic itself. 
> ...

 

Interesting; I*ll try this out. Does this work with suspend2? It seems so!

----------

## kernelOfTruth

 *Quote:*   

> Interesting; I*ll try this out. Does this work with suspend2? It seems so!

 

yes, unless you're encrypting your swap-partition (if you're using the swap-writer), file-writer seems to be a no-go if you're not using a unencrypted partition for it

mark, that shredding your old partitions / data takes a pretty long time,   :Rolling Eyes: 

here some more info for those being able to understand german (you can also search for it via google & then let it translate):

http://fedorawiki.de/index.php?title=Verschl%C3%BCsselte_Festplatten

http://de.gentoo-wiki.com/DM-Crypt

[url] http://www.linux-magazin.de/heft_abo/ausgaben/2006/10/loechriger_kaese/(kategorie)/362 [/url] 

[url] http://www.linux-magazin.de/heft_abo/ausgaben/2005/08/geheime_niederschrift/(kategorie)/362 [/url]

the last one is written by the author of luks ...

----------

## Roman_Gruber

hi thx for the links/urls. I am still reading.

What should I do if I have to keep my windows? 

I also want to keep my boot partition as ext2, which is also unsafer.

I*ll reinstall my gentoo and my datapartitions and will try this out!

Thx for pointing this out.   :Rolling Eyes: 

I am still reading: I have found: http://www.freeotfe.org/features.html This program seems to be for windows and seems to support DM crypt + LUKS (linux unified key setup). So It will be possible to access this data from windows. Great.

----------

## Roman_Gruber

Is this a problem?

Assume I have root encrypted and use a suspend2-swap-image + encyrypted swap for the system I assume that this swap image is then unencrypted and could be used then to break into the system!

----------

