Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Locking Up Linux, Creating a Cryptobook

ScuttleMonkey posted more than 8 years ago | from the operational-paranoia dept.


Tom's Hardware has a nice overview about some of the latest ways to secure your data looking specifically at open source solutions that wont lock down your credit card. Since many people presented performance issues for why they don't implement encryption there was also special attention given to how well your system will perform after implementation of encryption. From the article: "At least where LUKS is concerned, performance is hardly an issue - one must expect to pay some penalty for additional encryption facilities that handle unencrypted data transparently. All of these solutions are simple to set up and use on a daily basis, but LUKS is portable across Windows and Linux platforms."

cancel ×


Sorry! There are no comments related to the filter you selected.

Ob: frist mngggg (0, Flamebait)

Helen Keller (842669) | more than 8 years ago | (#15941494)

does gnnnnmmmmm beh linux?

Re:Ob: frist mngggg (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15941513) []

Re:Ob: frist mngggg (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15941735)

does this link to what i think it links to?

Meh! (as in motherfuckers!) (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15941499)

This would be a very interesting concept if Linux wasn't STILL for fags.

Re:Meh! (as in motherfuckers!) (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15941516)

the irony of reading this on slashdot...

hmmm... (0)

Anonymous Coward | more than 8 years ago | (#15941521)

I'll take the hardware encryption on my thinkpad anyday....

Hardware encryption (3, Insightful)

virtuald (996377) | more than 8 years ago | (#15941524)

Software encryption is fine, but there needs to be better and more widespread hardware encryption (NOT DRM) facilties that can be taken advantage of in a cross-platform manner..

No, software. (5, Insightful)

Kadin2048 (468275) | more than 8 years ago | (#15941591)

I'm not sure I agree with this.

Software encryption is really superior to hardware in many ways. Basically the only way it's usually not superior is in terms of speed, and this is why you see hardware encryption implemented.

However, as general-purpose computers have gotten faster and faster, so that there's more surplus capacity for things like encryption and decryption on the fly, I see the need for hardware encryption becoming less and less.

There's just no reason to restrict yourself to a hardware-based system that's hard to upgrade and fix, when you can use a software system that can be kept in tune with the state of the art and is a lot easier to trust. Even if I'm a relatively interested and intelligent person, there's no way I can 'open up' a hardware encryption module and see what's going on inside. With software encryption, I can look at the source code (and provided I'm using a trusted compiler and toolchain) know what it's doing.

Furthermore, software encryption leads to more diversity in implementations. When you use hardware systems, the only way they're affordable is if there is an economy of scale. You don't make just a handful (or even a few thousand) hardware modules, you want to make tens or hundreds of thousands of them. That means it's automatically going to be a big target. With software, everyone can use something that fits their needs more completely, and the exposure of the system as a result of a single exploit is reduced.

Hardware encryption was fine when computers were too slow to encrypt data that was being written to disk on-the-fly. But now they are, and this means that you can use regular equipment, and use whatever cryptographic implementation you want, and upgrade it as often as is required, with minimal additional expense. In fact, if I was going to build a "hardware" encryption device today, I'd probably just design it around a general-purpose system-on-a-chip so that it would be easily reprogrammable. I can't imagine that for anything but the most specialized, very speed-intensive tasks, that a custom-made hardware solution is really advantageous.

Not that I'm saying that all cryptographic hardware is bad; there is definitely room for specialized components without making entire hardware encryptors: dedicated hardware random number generators, for instance, seem like they'll definitely have a place for the foreseeable future.

Re:No, software. (1)

pc486 (86611) | more than 8 years ago | (#15941658)

There are hardware encryption accelerators that are being common. For instance, newish VIA's C3 processors have hardware RNGs, MAC, and AES engines that speed up the hard work in encryption.

Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.

Re:No, software. (2, Informative)

portmapper (991533) | more than 8 years ago | (#15942374)

Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.

The speeds reported are not believeable for a Pentium III M 1.2 GhZ even for just encryption. For comparisons, below is the output of "openssl speed" using a Opteron 170 (dual core, 2 GhZ):

timing function used: getrusage
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1319.99k 2852.42k 4012.43k 4463.32k 4616.59k
mdc2 0.00 0.00 0.00 0.00 0.00
md4 12368.68k 43225.00k 123294.14k 239186.25k 326060.22k
md5 10343.67k 34100.40k 89670.38k 154227.67k 192088.84k
hmac(md5) 12247.16k 38659.27k 98929.88k 161080.15k 197054.32k
sha1 10349.75k 32168.77k 77261.21k 118780.01k 141100.42k
rmd160 5952.92k 15180.22k 28828.97k 36378.64k 40787.12k
rc4 136573.04k 143986.99k 145413.62k 146386.75k 146586.59k
des cbc 34461.90k 35701.70k 37036.93k 37175.49k 36608.52k
des ede3 13751.49k 14061.98k 14140.86k 14095.64k 14166.87k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 21347.66k 21906.79k 21789.39k 22140.53k 21636.99k
rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00
blowfish cbc 65679.12k 71584.56k 72852.48k 73303.87k 73445.24k
cast cbc 53265.79k 56068.99k 56726.04k 57409.73k 57494.63k
aes-128 cbc 86677.02k 90569.60k 92748.63k 92012.46k 93433.72k
aes-192 cbc 75476.78k 80489.02k 81191.59k 82528.12k 82633.50k
aes-256 cbc 67846.54k 71592.09k 73376.29k 73320.49k 73532.54k

Re:No, software. (1)

Isao (153092) | more than 8 years ago | (#15941700)

Consider FPGA - the best of both worlds.

FPGA ftw (1)

drkfdr (785982) | more than 8 years ago | (#15942305)

I welcome the Virtex4 module for Opteron. Hope it's user-programmable. Such an FPGA can even contain seperately loadable modules. Perhaps someday Linux and Windows will be able to manage it automatically based on the applications that are currently running.

Hardware encryption is stupid, except on servers (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15941769)

As a desktop user, using hardware encryption will make no noticeable for anything. Even for servers, modern CPUs are so fast. A typical website spins its CPU on things like databases and bad PHP code. The SSL encryption hardly matters.

This isn't the 90s anymore. 2ghz CPUs are standard now. Dual CPUs are standard. I would be surprised if hardware encryptors have any edge over general-purpose CPUs these days.

Re:No, software. (1)

owlstead (636356) | more than 8 years ago | (#15942431)

I'm not so sure I agree with this. First of all, software encryption/decryption is prone to side channel attacks that are hard to defy ("listening" to the CPU to retrieve an RSA key). Hardware may be able to avert such attacks. A hardware random generator is also very nice to have, since it provides a high entropy source which is not dependent on other factors (making it less difficult to change hardware, funny enough).

Speed is also still an issue. I would like to see Tom's test repeated with a VIA C3 as well (I've a 1.2 fanless C3 laying right in front of me, so maybe I'll try when I get the memory for it next monday). If it uses AES, I really expect quite a speedup. CPU's are fast, but IO has quite risen to the challenge. I would really like to see CPU tests next to Tom's tests to see how much impact encryption/decryption has on system performance. Saying that hardware crypto is not needed is a bit like saying SSE3 is not needed IMHO.

CPU's are the best place for cryptographic accelerators. They already run on high speeds, communicate quickly with main memory. If the x86 manufacturers would agree on a specific instruction set (e.g. that one used by VIA) it would be great. As for compatability, just implement AES (128, 192 and 256 bits) for symetric encryption, SHA1, SHA-2 (256, 384 and 512 bits) for secure digests. Add a random number generator as well. RSA and EC (Eliptic Curves) is a bit optional, since they are hardly used for bulk operations on the desktop anyway. For application servers that depend on SSL, an RSA hardware accellerator (montgomery multiplyer) may still be a good idea though.

Re:No, software. (2, Informative)

mophab (137737) | more than 8 years ago | (#15943010)

In my experience, hardware encryption doesn't keep up with speed either. If you are using software encryption, it gets faster along with everything else as you upgrade to faster machines. Hardware encryption just does not keep pace with the increasing speed of general purpose processors.

The only remaining reason to keep hardware encryption around is to protect your private keys. Even in this way hardware can be problematic. If you have important private keys locked away in hardware, you need to have some backup plan if the hardware fails, or is not fast enough to meet future demand. So even in this case, you are probably better off with general purpose hardware that will protect/destroy its contents if physically attacked. Of course you can keep the hardware with the private keys on a secure subnet as well.

Re:No, software. (1)

Eternauta3k (680157) | more than 8 years ago | (#15945296)

I jthink what you mean by hardware encryption is either DRM (which you said you didn't want) or a dedicated encryption module (which for practicality's sake has to include software). If a PAL, GAL, PIC, cpu or else were used between the motherboard and the hard disk, you could have the speed of dedicated encryption with the versatility of reprogrammable encryption. Plus check if it was programmed to do what you expect it to...

Re:Hardware encryption (1)

lky (246353) | more than 8 years ago | (#15941639)

I've been running linux from an encrypted USB stick for a while (as discussed on [] ) and it works fast enough for everyday use. Just make sure you buy a real USB-2.0 Stick.

Re:Hardware encryption (0)

Anonymous Coward | more than 8 years ago | (#15941783)

Given the number of hardware bugs that we have to work around on a daily basis in BIOSs, wireless chipsets, graphics cards, etc. The last thing we need is another buggy piece of hardware. I agree in principle that it "should" be done in hardware, but in practice hardware vendors don't have the requisite paranoia and perfectionism necicary for the world of cryptography. I would much rather have my cryptography written and checked by thousands of paranoid open source developers than one company that doesn't really care if it actually works, as long as no-one finds out before they have a new model on the market. Hell, most likely any hardware system that gets populer will be back doored at the NSA/FBI/Homeland Securities request, just like their pushing for routers.

Not available in UK (2, Informative)

LiquidCoooled (634315) | more than 8 years ago | (#15941528)

Apparantly, from the UK redirects to which doesn't have the article.

Thats just annoying as hell.

Re:Not available in UK (1)

Cap'nPedro (987782) | more than 8 years ago | (#15941671)

Re:Not available in UK (0)

Anonymous Coward | more than 8 years ago | (#15941743)

Has ANYONE here ever been able to succesfully view a coral cached page? Either times out for me or just takes so long that I guve up (I.E. 20 minutes later the html is still loading.)

Re:Not available in UK (2, Informative)

Per Wigren (5315) | more than 8 years ago | (#15941850)

Has ANYONE here ever been able to succesfully view a coral cached page? Either times out for me or just takes so long that I guve up (I.E. 20 minutes later the html is still loading.)

That sounds like outgoing connections to port 8080/8090 are blocked for you. Are you behind a restrictive corporate firewall?

Multi-user laptops (4, Informative)

Gopal.V (532678) | more than 8 years ago | (#15941532)

Now, this might not be a common thing in the US. But here in India, a lot of companies have team laptops which we pass around (on-call duty for server pages, for instances).

And somebody from Delhi, did something up which works for exactly that. qryptix [] encrypts your home dir and mounts using your passphrase when you login, built as a pam.d module.

Except for the fact that I wanted a truecrypt [] built into it, so that I can have a hidden volume even after I pass-phrase in to the first volume, this works well enough for most purposes.

Re:Multi-user laptops (1, Informative)

Anonymous Coward | more than 8 years ago | (#15941650)

A similar project of note is pam-mount [] , a pam module to mount (usb|smbfs|losetup+crypt|LUKS|whatever) on login and umount upon logout. Too bad this is a performance-centric article, there are some very interesting things one can setup with (LUKS|device mapper|losetup). For instance encrypting your /tmp+swap with one-time keys from /dev/urandom.

Re:Multi-user laptops (0)

Anonymous Coward | more than 8 years ago | (#15942493)

Truecrypts 'plausible deniability' option does rely somewhat on its encrypted second volume being indistinguishable from the random data written to the disk when the volume was created.

Merely comparing the current file with any (siezed) backups would put lie to that caper, and a competent computer forensics lab should still be able to deduce whether the 'unused' sectors have been recently changed in any case.

So, useful yes, but not something that'll necessarily keep you out of jail.

encryption vs security (3, Insightful)

Keruo (771880) | more than 8 years ago | (#15941541)

Encryption won't protect you from hackers if you have the drives mounted 24/7.
It's only good for protection against stolen data, eg. usb drives or cds/dvds.
Or, if you keep your entire computer at unsecre location, and are afraid that someone will steal the entire machine(root crypto).

But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)
Encryption won't give you perfect cover, but if you really have something valuable to protect, it's decent way to go.
Performance WILL be an issue, don't be blinded with those luks graphs, real world performance will be much closer to the cryptfs/encfs performance numbers, but it's fast enough. Just encrypt what you have to. No need to encrypt entire system if you can get away just by encrypting home dir.

Re:encryption vs security (2, Interesting)

CastrTroy (595695) | more than 8 years ago | (#15941560)

Well, I'm running an encrypted swap partition, and frankly, I haven't noticed any slow down. Granted, I have 1 gig of RAM, so I don't go into swap too often, but I find that it doesn't actually slow down your computer too much. You might notice if you don't have enough RAM, or if you encrypt your home partition, and then try to use if for video editing and other hard storage usage applications. However, if your using it on your laptop for business, you probably won't notice much of a difference.

Re:encryption vs security (1)

Keruo (771880) | more than 8 years ago | (#15941595)

I was talking about encrypted data partitions, not just swap,
but encrypting swap is as(or even more) important than encrypting data.
I agree with you fully with that point.

Re:encryption vs security (5, Informative)

Anonymous Coward | more than 8 years ago | (#15941741)

But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)
That's bullshit. If your implementation is vulnerable to this, then it's flawed.

Re:encryption vs security (5, Informative)

owlstead (636356) | more than 8 years ago | (#15942468)

Mod parent up - if I do, I loose my own addition to the discussion. Most block ciphers are quite immune to known plain text attacks. This is at least true for DES and AES. And well implemented stream ciphers are as well (I specifically say "well implemented" because of the the flawed WEP implementation for WiFi).

Re:encryption vs security (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15941773)

"But remember, encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)"

If the encyrption is done properly, then naturally whole partition is encrypted (including ext3 header etc..).

"Performance WILL be an issue, don't be blinded with those luks graphs"

No it won't, unless you will run a file server or something similar. Do you think that in the average use it will matter wherever your HDD's read speed is 20MB/s instead of 50MB/s?

Re:encryption vs security (0)

Anonymous Coward | more than 8 years ago | (#15941944)

Have you ever, ever heard of an initalization vector?

Re:encryption vs security (1, Informative)

Anonymous Coward | more than 8 years ago | (#15943670)

Apparently not. And the scary thing is, those are the kind of people who hack together yet another VPN or other crypto-software with massive flaws in them.

See pn.txt [] about how hobbyist "security" software can really suck.

Re:encryption vs security (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15942328)

Not only is the parent post not insightful, it's just plain wrong. A correctly implemented encrypted disk won't have "specific information at specific blocks", and unless you routinely run your computer at full-steam all the time, performance WON'T be an issue.

Re:encryption vs security (2, Informative)

Beryllium Sphere(tm) (193358) | more than 8 years ago | (#15942956)

>encrypted filesystems are vulnerable to cryptanalysis since they contain specific information at specific blocks even if encrypted(ext3 header etc..)

Part of the minimum design criteria for a crypto algorithm is to resist "known plaintext" attacks, such as knowing the location of magic numbers, headers, and so on.

Re:encryption vs security (1)

msobkow (48369) | more than 8 years ago | (#15946723)

Encryption isn't supposed to protect you from crackers and script kiddies. It's supposed to protect you from media theft and traffic interception/interference. Why expect a tool to provide some miraculous protection it was never designed to?

Crackers can't get to the machine unless it's connected. If your data is important enough to encrypt, WTF are you doing leaving the box exposed to the 'net? The only thing a secure box should expose is the services used to access the secured data.

  1. Create chroot tree for encrypted service.
  2. Set up specific user id for encrypted service.
  3. Use encfs to encrypt appropriate data portion of encrypted service chroot tree.
  4. Lock down the service user id from (2).

That should let you isolate the service data files so that they are only accessible through the chrooted service. Shift that over to a VM or a seperate node, and the odds of intrusion are actually rather slim -- especially if you're talking about a service to applications, not an internet service.

As to personal data, use multiple encfs or truecrypt "volumes" so that they are only mounted when using a particular utility. For example, I keep different projects in different volumes, and mount the one I'm working on. In a sense, each project has it's own "VM" because all of the configs and data for Eclipse, a database, JBoss, etc. are in such a volume.

Rather than being painful, it's kind of handy. I configure every project the same, so all I have to do is make sure I mount a project before running a standard service up/down script that all the projects use. Plus it avoids all that painful nonsense involved with trying to run multiple service configurations on one box when you don't have enough memory for a real VM solution.

Security First (1)

Doc Ruby (173196) | more than 8 years ago | (#15941553)

Which Linux (not BSD) distro is the most locked down secure from initial install? Regardless of other ease of use, or performance. Debian origin (for apt-get) preferred.

Since performance seems the biggest tradeoff, which "crypto coprocessors" (PCI DSP/FPGA/ASIC/etc) have Linux OSS drivers?

Re:Security First (3, Informative)

kneeless (837507) | more than 8 years ago | (#15942836)

Debian Etch will have an option to use encryption by default and encrypt all partitions (except boot). This one article details how to encrypt all partitions except boot: []

Re:Security First (0)

Anonymous Coward | more than 8 years ago | (#15944131)

This discussion comes at the right time, but I've already visited all my local (real) computer stores and googled(R) around to no avail. There ain't ANY cryptochips supported for Linux currently (a company named "Soekris" however apparently working on one for their weak cryptochip version). So I actually really consider Free/OpenBSD for the switch (they have apt, but no binary repositories or so I've heard), whatever.

Some interesting discussions (1, Troll)

maxpow (879014) | more than 8 years ago | (#15941582)

I found some interesting discussions [] about linux data security. Good read!

TrueCrypt? (5, Interesting)

SirClicksalot (962033) | more than 8 years ago | (#15941590)

A pity they don't mention TrueCrypt [] .

Besides encrypting your data, TrueCrypt can also create hidden volumes:
"The principle is that a TrueCrypt volume is created within another TrueCrypt volume (within the free space on the volume). Even when the outer volume is mounted, it is impossible to prove whether there is a hidden volume within it or not, because free space on any TrueCrypt volume is always filled with random data when the volume is created* and no part of the (dismounted) hidden volume can be distinguished from random data. Note that TrueCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way."

So even if you reveal your password, the hidden volume stays safe. Not a bad feature, considering it is a crime in many countries to refuse to give your encryption key to the authorities...

Re:TrueCrypt? (1)

treval (89829) | more than 8 years ago | (#15941721)

It seems like a neat idea until you consider that the 'authorities' will assume that there is a hidden volume (and encrypted data) simply by virtue of using TrueCrypt in the first place.

Then you are faced with proving that there isn't any encrypted real data amongst the random free space...

Re:TrueCrypt? (1)

Grym (725290) | more than 8 years ago | (#15941772)

Then you are faced with proving that there isn't any encrypted real data amongst the random free space...

Which is, for all intents and purposes, impossible--putting the burden of proof on your adversaries. In court the suspicion or possibility of there being something more is circumstancial evidence at best.


Re:TrueCrypt? (1)

TerryMathews (57165) | more than 8 years ago | (#15941979)

Yes, but that standard only exists in countries that don't compel you to give up your encryption key in the first place.

You're talking US, UK, Canada. Parent is talking Syria, Lebanon, Iran.

Re:TrueCrypt? (2, Informative)

rich_r (655226) | more than 8 years ago | (#15942141)

No, it's a crime to not give up your encryption key in the uk. Furthermore, it's the only crime for which the burden of proof is on the accused. Don't have a link to hand, but I believe it's the RIP act of '99. (commentary here [] )

Re:TrueCrypt? (1)

adamofgreyskull (640712) | more than 8 years ago | (#15943613)

It is a crime in the UK to refuse to give up encryption keys. The original maximum sentence I believe was 2 years, but now, with the "new" threat of terrorism (No-one else remember manchester & brighton? Anyone?) they want to increase that. So this guy [] can be locked away for even longer, because he's obviously got encrypted plans for a dirty bomb on his hard drive.

I'll leave the US as an exercise for another.

Re:TrueCrypt? (2, Insightful)

Rich0 (548339) | more than 8 years ago | (#15942623)

So, then you put a hidden share in, and then put another hidden share inside that hidden share. Truecrypt hidden shares can be an arbitrary number of levels deep, and unless the authorities intend to just beat you until you die they're going to have to figure at some point that you might just be telling them the truth when you say there isn't another level...

The design of truecrypt is that it isn't possible to tell whether there is a hidden volume or not - it just looks like unused space.

Re:TrueCrypt? (1)

Shadyman (939863) | more than 8 years ago | (#15942844)

Wouldn't it all look like "used" space, though, if it's filled with random characters?

Re:TrueCrypt? (2, Informative)

Rich0 (548339) | more than 8 years ago | (#15943702)

Truecrypt volumes are filled with random data when they are initialized, and appear random when files are created/deleted. There is nothing you can do to tell whether a volume was ever written to without knowing the key.

So, yes it does look like "used" space. But it also looks like "empty" space by the same virtue. If you just put your regular checkbook in a truecrypt volume and put something else in a hidden volume it would be plausible to say that the checkbook is the only thing in there.

Just fill the volume with files... (0)

Anonymous Coward | more than 8 years ago | (#15944157)

A way to find out if there's hidden data is to fill up the volume with files, no? "Hm, this says the disk is full, but by my count there's 180MB missing somewhere."

Re:Just fill the volume with files... (0)

Anonymous Coward | more than 8 years ago | (#15944335)

No, it just overwrites the data. After you have mounted a hidden volume, you can tell truecrypt to reserve the space so that it is not overwritten by the parent volume. But without knowing the passphrase, you can't even know if there is a hidden volume there.

Re:Just fill the volume with files... (1)

Rich0 (548339) | more than 8 years ago | (#15945620)

Correct - to clarify:

If you mount a truecrypt volume that contains a hidden volume and you don't specify the hidden volume passphrase then it just mounts the non-hidden volume. The non-hidden volume behaves as if it occupies the full space of the file/device it is contained in - if you write lots of data it will keep on writing right over the hidden volume, destroying it (without any way to tell this is happening). The only way to safely write to the outer volume is to mount it with the passwords to both volumes - which then lets it protect the data in the hidden volume when modifying the outer volume.

License (0, Flamebait)

Anonymous Coward | more than 8 years ago | (#15942418)

The worst thing about TrueCrypt, it seems, is the license. They claim that it's "free open-source", but this is not obvious when reading the license (which is its own funky license, not a standard one).

Debian, for example, has not packaged it due to the license.

It's a shame that everybody thinks they need their own special license for their program. Bleh. You are not special. You are not a unique snowflake. If you want to write an open-source program so people can use it, then don't make a custom license that prevents it from going into common Linux distros, dorks.

Printable view of TFA (2, Informative)

pair-a-noyd (594371) | more than 8 years ago | (#15941664)

If you have the 400 page ad loaded version as much as I do. linux-creating_a_cryptobook/print.html []

Re:Printable view of TFA (2, Funny)

pair-a-noyd (594371) | more than 8 years ago | (#15941676)

Shit, coffee malfunction, I meant to type "hate" not "have"....

Gee, I should have submitted this.... (0, Offtopic)

Penguin Follower (576525) | more than 8 years ago | (#15941670)

I was reading that Tom's article this morning around 8am EST. Oh well!

What is up with performance concerns and crypto? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15941709)

Every time you write a block to disk, it goes through a cryptographic checksum. Every time you send a TCP packet it goes through a checksum. The amount of CPU needed to do these checksums is not much different from the amount of CPU needed to do full encryption. We routinely use compression, which takes more CPU. If someone out there is thinking, "I would love to encrypt but I'm worried about performance", he's probably using a Mac Plus or a PC Jr or something. That isn't reality. Modern CPUs pipeline all these operations and do them so fast it will make no noticeable difference in anything.

Don't forget, encryption makes you terrorist (1)

steincastle (995168) | more than 8 years ago | (#15941730)

Well mostly, the "issues" are more complicated then one might think:

Encryption is classified as a munition under the Internation Traffic in Arms Regulations (ITAR)

source: []

Transfer saved video from old to new would sell me (0, Offtopic)

DrTime (838124) | more than 8 years ago | (#15941844)

I have two DirecTV Tivo units and I will keep them until they die unless the replacement offered has a way to transfer my saved videos to it. All I ask for is a one time transfer. Through a software download update, they enable a USB to Ethernet or USB to USB way to connect my old machines to the new one and transfer my videos. They can even be deleted from the old machine as they are copied.

Of course having some decent HD content would also help.

Letting me get files from the DCR to my computer would be nice, but is not realistic.

Re:Transfer saved video from old to new would sell (0)

Anonymous Coward | more than 8 years ago | (#15942270)

Errr... What?

loop-aes not mentioned (0)

Anonymous Coward | more than 8 years ago | (#15941909)

Quite useless article when the most advanced and mature Free Software disk encryption system for GNU/Linux is not mentioned.

TWO WORDS (for overhead issues) (0)

Anonymous Coward | more than 8 years ago | (#15942186)

Dual processors

My experience (5, Informative)

cvalente (955264) | more than 8 years ago | (#15942229)

I've been running my desktop on an encrypted root partition using LUKS (on Gentoo via dm-crypt) for over 6 months now.

I was afraid that heavy IO access might cause high CPU usage or that some FS might not play all that well with the encryption.

So far, I've had no problems. Even copying from one encrypted partition to another encrypted partition causes no noticeable lag due to encryption and normal usage of my disk, even with heavy uses such as DBs or backups seems to take place just like before.
I've been using LUKS with xfs (and reiserfs to a lesser extent). I have a P4 3.2Ghz, don't remember the disk specs.

Being able to have several passphrases is a good thing (you can even change them later on) and the assurance that a weak passphrase will not cause the key being easily guessed via crypto-analysis is another plus.

The downside is that booting from an encrypted partition can be a little difficult to setup for a novice, but that has been improving and at least Gentoo now offers this on the current genkernel with little extra hassle.

If you want the whole package, you can even encrypt the swap partition with a randomly generated key at boot time.

What do you get from all this?

Suppose your computer has an hardware malfunction and you have to send to be repaired (warranty for instance). You can be sure no one will find the financial data you saved there, or some less flaterring photo (or something more embarrassing you didn't even remember). Using an encrypted partition to save sensitive data might be enough, but many programs end up saving temporary data in unexpected places so all that care might be useless in the end. If everything is encrypted that risk is gone with just a little bit of extra work (once).

Like someone wrote, this won't protect you from having you computer hacked while the partition is mounted and stealing data.

Re:My experience (0)

Anonymous Coward | more than 8 years ago | (#15946218)

You're an idiot if you send your computer in for repair with the hard drive in place. I always remove the drive if I need to give my computer to someone else I don't know.

eCryptfs (3, Informative)

omnirealm (244599) | more than 8 years ago | (#15942525)

I am disappointed to see that Justin Korelc and Ed Tittel entirely missed eCryptfs [] , which is already in the -mm tree of the Linux kernel.

Linux can lock up? (1)

bergeron76 (176351) | more than 8 years ago | (#15942705)

For a minute there I thought that someone had "locked up" the linux kernel in the "Windows lock up" style. Whew...

Formats and upgrades (2, Interesting)

pe1chl (90186) | more than 8 years ago | (#15943698)

A problem with Linux encrypted partitions is that there are several formats, and no migration path.
As usual, when new and better solutions are developed, the Linux developer scene does not really care about backward compatability. The new method is sooo good that the old one should be left in the dust and its adopters must backup and restore.
Developers who suggest backup and restore must be unaware of the current market situation w.r.t. backup solutions and their capacity vs that of IDE disks...

Recently I decided to move two disks from my main system, encrypted under SuSE 9.2, to another box that I want to dedicate to background storage.
I remembered that I had read about some issue in 9.3, but I believed that it had been long solved so I installed SUSE 10.0 on this new box.

There was NO WAY I could get the disks mounted. I tried all the tricks found in several articles on Internet, but I kept getting errors.
The SuSE knowledge base stated that everything would be fine when I just upgraded the OS, but I don't believe that because I tried the solutions equivalent to what would happen when upgrading. I don't want to risk it.

Finally, the only solution was to install 9.2 on the new box, and the disks worked OK. Then, I have bought more disks (as was the plan) and copied the data from encrypted to unencrypted disks. Next step will be to install 10.0 again, but I am not so sure if I will encrypt the disks again as the 10.0 system is (I believe) not LUKS so probably at 11.0 I will again face the same problem because the "all new and better LUKS" is now the supported system.

I will not even think about what would happen when I would want to change the distribution from SuSE to RedHat or Ubuntu or whatever.
Chances must be about zero that I can still access the data.

There is not even a tool that would in-place decrypt (or encrypt, for that matter) the data on a partition. Even when one wants to take the risk that it interrupts halfway and destroys everything. So you always need a source and destination device with enough space.

Please keep this in mind before you encrypt your terabyte volumes...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>