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!

Ask Slashdot: Tools For Linux Disk Encryption and Integrity?

timothy posted more than 2 years ago | from the guaranteed-wrongness dept.

Encryption 123

An anonymous reader writes "I have been using Gentoo Linux for a long time now and have always been satisfied with one of its many disk encryption tools: cryptsetup (dm-crypt and LUKS). However, I recently gave FreeBSD a try and, although I concluded BSD is not for me, I was amazed at geli(8), FreeBSD's disk encryption tool. It happens this tool also provides what it calls an 'authentication mode.' Besides encrypting the disk sector-by-sector, it also stores checksums (sha256 in my case) in it on every write. On reads, if the checksum mismatchs, it propagates the error up, resulting in, say, a read() error. Thus I do not have to trust my disk (except of course for the boot partition) any longer: any data inconsistency will be detected before the data is used. Having searched for a long time without answers, I want to ask: is there something similar to this in Linux? Note: Using Btrfs is a valid solution, but is far from stable (got a few oopses during my tests)."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Yep (5, Informative)

Anonymous Coward | more than 2 years ago | (#36467992)

You can use IMA (2.6.30 and later) and EVM (2.6.38 and later). :)

Re:Yep (0)

Anonymous Coward | more than 2 years ago | (#36472194)

How about some links?

ZFS? (1)

johnslater (61055) | more than 2 years ago | (#36468014)

ZFS has checksumming on every block

Re:ZFS? (0)

Anonymous Coward | more than 2 years ago | (#36468056)

Yeah, Linux was a requirement, Doofus.

http://zfsonlinux.org/ (-1)

Anonymous Coward | more than 2 years ago | (#36468132)

All I have to say to tha is http://zfsonlinux.org/

Re:http://zfsonlinux.org/ (1)

bigredradio (631970) | more than 2 years ago | (#36468356)

From the zfsonlinux.org site:

Please keep in mind the current 0.5.2 stable release does not yet support a mountable filesystem.

And considering that btrfs was not stable enough for the author, I don't think that is an option either.

Re:ZFS? (0)

Anonymous Coward | more than 2 years ago | (#36470664)

ZFS-Fuse? Or share iSCSI volume to linux client and keep ZFS on the backend.

TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36468022)

Check out TrueCrypt, http://www.truecrypt.org/ [truecrypt.org]

Re:TrueCrypt (3, Informative)

munozdj (1787326) | more than 2 years ago | (#36468092)

Yes, exactly. I've been using TrueCrypt for my important info (mostly pr0n), and have had no problems. It lets you choose between different encryption algorithms (blowfish, twofish, AES, and others I can't remember) and allows you to encrypt individual files, mount an encrypted virtual volume or encrypt your entire hard drive. And, as usual on /., its FOSS.

Re:TrueCrypt (1)

zonky (1153039) | more than 2 years ago | (#36468174)

*insert TrueCrypt license debate here*

Oh go on, i'll start it off.
There are some who would argue the license is dangerous.

Re:TrueCrypt (1)

boristhespider (1678416) | more than 2 years ago | (#36469304)

Why's that?

Honest question, I've not heard the argument.

Re:TrueCrypt (1)

Threni (635302) | more than 2 years ago | (#36469524)

Have you read the license? Not GPL, Apache etc. Not really open source, although the source is available.

http://fedoraproject.org/wiki/ForbiddenItems#TrueCrypt [fedoraproject.org]

Re:TrueCrypt (1)

geminidomino (614729) | more than 2 years ago | (#36470108)

The link says that Fedora says the license is dangerous, but doesn't go into it at all.

Here [debian.org] is a more detailed explanation on the dangers from debian-legal, though it's 5 years old so I can't say whether or not it's even still relevant...

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36468148)

I'm pretty sure TrueCrypt system encryption only works with Windows. For Linux, it only allows containers.

Re:TrueCrypt (2)

EkriirkE (1075937) | more than 2 years ago | (#36468222)

Nope, it offers full disk encryption, partition encryption, and file container, regardless of filesystem type within on Linux. My only problem with in on linux is the partition labels do not propagate thru mounting (eg /media/truecrypt1 instead of /media/MyDiskLabel)

Re:TrueCrypt (3, Informative)

Jeremiah Cornelius (137) | more than 2 years ago | (#36468254)

Volume encryption?

Why is it needed? Unless you have a requirement that dictates this, there are more ways for volume encryption to fail.

I am surprised no one has mentioned encfs. You could run it in userspace over whatever precious checksumming system your heart desired.

http://www.arg0.net/encfs [arg0.net]

Advantages of pass-thru system vs an encrypted block device

  • Size: an empty EncFS filesystem consists of a couple dozen bytes and can grow to any size without needing to be reformatted. With a loopback encrypted filesystem, you allocate a filesystem ahead of time with the size you want. Depending on the filesystem, there may be ways of resizing it later, but that requires user intervention.
  • Automated Backups: An EncFS filesystem can be backed-up on a file-by-file basis. A backup program can detect which files have changed, even though it wonâ(TM)t be able to decipher the files. This way backups can be made without needing to mount the encrypted filesystem.
  • Layering / Separation of Trust: EncFS can be layered on top of other filesystems in order to add encryption to unencrypted filesystems. This also allows you to store data on filesystems you trust for storage but not for security. For example, EncFS could be used on top of a CD, or a remote NFS filesystem, Samba share, or perhaps even GMail storage using GMailFS.


  • Meta-data: Meta-data remains visible to anyone with access to your encrypted files. This means that Encfs does not encrypt or otherwise hide the following information:
    • The number of files you have encrypted
    • The permissions on the files (readable, writable, executable)
    • The size of each file
    • The approximate size of each filename (to within 16 bytes using AES, or 8 bytes using Blowfish)

Re:TrueCrypt (1)

mlts (1038732) | more than 2 years ago | (#36470558)

What I find ironic is that Google has not included this with Android, as it is the perfect tool for securing data on SD cards.

Re:TrueCrypt (0)

synthespian (563437) | more than 2 years ago | (#36471832)

Rather than using some obscure thingo nobody's heard of, made by whats-his-name, I would speculate that the FreeBSD is safer, because they have people who understand crypto.

Philip Zimmer (of PGP fame) used to say that most people screw up in the implementation part.

Now, TrueCrypt you can trust, because it was used in a high-profile financial case in Brazil (it was mentioned here in Slashdot) and the Feds from Brazil and the USA (Brazilians asked for help) couldn't get the data out.

All charges against the banker Daniel Dantas (although this had nothing to do with TrueCrypt).

http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-truecrypt/ [techworld.com]

Needs translating:
http://g1.globo.com/politica/noticia/2010/06/nem-fbi-consegue-decifrar-arquivos-de-daniel-dantas-diz-jornal.html [globo.com]

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36468324)

truecrypt uses FUSE which is a performance hit. it's ok for backup storage though.

Without checksumming? (1)

bluefoxlucid (723572) | more than 2 years ago | (#36468058)

What? What do you mean? You mean someone would be retarded enough to write an encryption method that doesn't use ECC or such internally?

Re:Without checksumming? (1)

Anonymous Coward | more than 2 years ago | (#36468140)

dm-crypt doesn't protect you against someone who is manipulating your hard drive while you're using it. It's intended to protect you after the hard drive is stolen. This is how most full disk encryption software works. It's not really "retarded".

Use VDMFEC or other FEC for ECC (1)

RowboatRobot (899380) | more than 2 years ago | (#36471110)

What? What do you mean? You mean someone would be retarded enough to write an encryption method that doesn't use ECC or such internally?

Most encryption algorithms, whether implemented on a file or real-time on a disc, are not primarily concerned with ECC. Plenty use hashes, but not for the purpose of correcting errors caused by disk corruption. There are even less of the kind the author is looking for (real-time total disc encryption with ECC seamlessly integrated). It's not my speciality so I don't know of them

But if we're talking about sending and receiving data from long-term storage (rather than real time), that is easily attainable if you separate the encryption and error detection tasks. For error detection, and just as important, being able to fix those errors when they happen (two separate things) the term you're looking for is Forward Error Correction (FEC) software. If you're serious about backing up your data, and it still being around and undamaged in a few years, you should be serious about FEC. It amazes me how many enterprise-level companies frequently back up millions of files, but have no strategy for ECC.

Using vdmfec (my favorite FEC software. For linux), say you have a file that is 1gb that you'd back up with it (Large archive files are especially important to use forward error correction on, because plenty of them, if they get data corruption in the wrong place, get totally screwed up.) So, let's say with vdmfec you select the blocksize to be 5 kb, and then you select two positive whole number parameters, K and N. For every original K blocks, N blocks are written so that if up to N-K fail, you can still recover all original K blocks.

In plain english, if I set a K value of 10 and an N value of 30, then the first 50kb of the file would be transformed into 150kb. There could be quite a few bits accidentally flipped in that 100kb over time, but as long as any 10 of the 30 blocks did not suffer any damage, that set of blocks would be entirely fine. You can pass different K and N arguments according to your needs (reliability v. size) for a reasonably reliable disc over the short term, K=15 and N=20 would do just fine.

For encryption, use whatever you'd like, total disk encryption, folder encryption etc. One concern is that if you use any error detection or correction, it establishes a reliable data pattern which can be used to break the encryption. This concern can be solved by encrypting before applying error correction instead of after, or using encryption of sufficient bitstrength so that it will take another several decades for the hardware to be developed to crack it.

Re:Without checksumming? (2)

gweihir (88907) | more than 2 years ago | (#36471286)

You have no clue about block-oriented storage encryption, obviously. There is no space for checksums and the task is done on a lower layer (the disk) and can be done on filesystem layer. Doing it on block layer in addition to the encryption breaks block alignment.

Just use a (0)

Anonymous Coward | more than 2 years ago | (#36468060)

Just use a one-time pad.

Re:Just use a (1)

TheSpoom (715771) | more than 2 years ago | (#36468150)

Absolutely. Just take an extra hard drive with the pad on it whenever you need to access your data...

Re:Just use a (0)

Anonymous Coward | more than 2 years ago | (#36468912)

Ah, hearing that reminds me of Telenet and Phrack/2600. Now get off my lawn!

CNET (of all places) Review (-1)

Anonymous Coward | more than 2 years ago | (#36468068)

Believe it or not, CNET did a great review [youtube.com] of the options available for encrypting HDDs.

Why is FreeBSD not for you? (0)

Anonymous Coward | more than 2 years ago | (#36468080)

Since I've been using FreeBSD for a decade now and I like geli very much, it's not very interesting for me what Linux alternatives there are. But one thing is interesting... why did you decide that (Free)BSD is nothing for you?

Re:Why is FreeBSD not for you? (-1)

Anonymous Coward | more than 2 years ago | (#36468100)

Because he's a Linux zealot freetard.

Re:Why is FreeBSD not for you? (-1)

Anonymous Coward | more than 2 years ago | (#36468614)

and you're a spineless proprietary ca$htard... or a spineless code thieftard...yay!

Re:Why is FreeBSD not for you? (0)

Anonymous Coward | more than 2 years ago | (#36470636)

Wow, that's one of the worst comebacks from a freetard of all time.

Re:Why is FreeBSD not for you? (1)

hedwards (940851) | more than 2 years ago | (#36468340)

Probably the same reason why Linux is my main OS right now rather than FreeBSD, there's a few specific applications which I haven't been able to get running on FreeBSD, which work fine on Linux. Most applications can be made to work on FreeBSD if they work on Linux, but a few like Truecrypt won't.

Re:Why is FreeBSD not for you? (1)

utkonos (2104836) | more than 2 years ago | (#36469142)

How is it that you didn't get TrueCrypt working? The current version is in the ports collection and works fine for me: http://www.freebsd.org/cgi/url.cgi?ports/security/truecrypt/pkg-descr [freebsd.org]

Re:Why is FreeBSD not for you? (1)

webmistressrachel (903577) | more than 2 years ago | (#36469668)

Hmmm, I believe you just bit a very common troll, how does it taste?

Surely you've seen the "BSD doesn't support xyz" (where BSD clearly does support xyz) troll before? The other one we see a lot here is the "Netcraft confirms it... BSD is dying". That one never gets replies, though.

Your comment is informative, however.

TrueCrypt (1)

wallyhall (665610) | more than 2 years ago | (#36468138)

Nuff said.
http://www.truecrypt.org/ [truecrypt.org]

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36468392)

I have no experience with TrueCrypt in Linux, but if it's half as good as in Windows, I agree.

Re:TrueCrypt (2)

Chryana (708485) | more than 2 years ago | (#36468440)

As far as I am concerned, you already said too much. Your post does not even remotely address the question asked. Please read the summary next time. As for the original poster: sorry, I don't know any such tool for Linux. ZFS has already been mentioned. Maybe you could compile Geli on Linux?

Re:TrueCrypt (2, Informative)

koolfy (1213316) | more than 2 years ago | (#36468502)

Not TrueCrypt. [wikipedia.org]
Nuff said.

also : https://tails.boum.org/support/truecrypt/index.en.html [boum.org]
I'll never say this enough : Don't trust Truecrypt when you have a shitload of similar/better tools that you can actually trust on linux.

I mean just look at this [slashdot.org]

Re:TrueCrypt (1)

wallyhall (665610) | more than 2 years ago | (#36472214)

You've been modded down - I think that's a shame. You've made a discussion point - and been penalised for it.

What such tools would you suggest? Your last two linked articles don't work for me - could you summarise their content?

I suggested TrueCrypt because the NHS in the UK use it quite a bit (so I'm informed), for a free product (and one which I believe the source code is available for) it does the job quite nicely IMHO.

Re:TrueCrypt (2)

koolfy (1213316) | more than 2 years ago | (#36472460)

sorry the correct link was : http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software [wikipedia.org]

I Usually use LUKS with DM-Crypt [gentoo-wiki.com], but there are other tools more user-friendly that come with gnome.
Last day I discovered a gnome applet that manages crypted volumes written on the fly as you modify the mounted folder, that scale with the size of the content of the volume. (Dm-crypt has a defined volume size that you cannot outgrow, and the chiffered file used to mount the volume always has the maximum size it can reach --If I want a 15gB crypted volume, I get a 15gB file, no matter how empty the volume is.)

I know avoiding TrueCrypt sounds like tinfoil hat paranoia, but if you need te encrypt your data in the first place, maybe this is healthy paranoia.

Re:TrueCrypt (1)

Threni (635302) | more than 2 years ago | (#36469502)

Not open source. Do keep up.

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36470364)

TrueCrypt is open source. Do keep up.

Re:TrueCrypt (1)

Ranguvar (1924024) | more than 2 years ago | (#36470508)

Not open source.

The code is available, but under terms of a license so insane that neither the FSF nor the Open Source Initiative (who maintain the definition of 'open source': on their list of approved licenses) consider it free.

This is also one of the reasons RMS prefers free/libre software -- it avoids this whole "well it's open, but not really" ridiculousness when it comes to insane licensing.

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36472278)

I don't give a fuck about what the FSF considers to be free software. The code is available, which means that it can be audited. That's what I'm interested in when dealing with a security product.

What? That no one external to the project has reviewed the code despite being publicly available? Well, that tells you all you need to know about the Million Eyes Reviewing Source Code myth.

Re:TrueCrypt (0)

Anonymous Coward | more than 2 years ago | (#36471674)

It is open source, code is available for download and you can make and distribute derivative works or do a code review.

It does not, however, feature a gpl license or an open development model.

Re:TrueCrypt (1)

wallyhall (665610) | more than 2 years ago | (#36472198)

Sorry, please excuse my ignorance - (that's expressed honestly, not sarcastically) - I wasn't aware the OP was interested in only GPL? (Or am I missing something ... in which case I apologise profusely!)

Just trolling (0)

bigredradio (631970) | more than 2 years ago | (#36468318)

I have been using Gentoo Linux for a long time now

No takers?

Re:Just trolling (0)

Anonymous Coward | more than 2 years ago | (#36468342)

I have been using Gentoo Linux for a long time now

No takers?

Being a Gentoo user myself, I'm surprised at the lack of "LOLricerGTFO" comments. Maybe they're stuck in rush hour and we just have to wait a little longer?

Re:Just trolling (0)

Anonymous Coward | more than 2 years ago | (#36468876)

Oh what sad times are these when /. posters don't even bother to make a simple Ricer comment to admitted Gentoo users anymore. What has become of this site, once so proud and lively? It now stands rigid, unmoving, possibly covered in hot grits.

Re:Just trolling (3, Insightful)

greg1104 (461138) | more than 2 years ago | (#36468990)

Gentoo recently postponed using GNOME3 [blogspot.com] because it seemed like a "work in progress". Meanwhile, Fedora has shipped it, Ubuntu is now on the even less mature Ubiquity, and CentOS can't even get a modern release shipped out the door at all. Gentoo is looking like a stable Linux aimed at old geezers nowadays.

Re:Just trolling (1)

NateTech (50881) | more than 2 years ago | (#36470916)

Or Linux desktops still just look like the metric ass-load of crap they've all been since Enlightenment.

Re:Just trolling (1)

Bert64 (520050) | more than 2 years ago | (#36472366)

The beauty of Gentoo is that you can mix and match...
There is a gnome3 overlay if you want it.

I like being able to have control over the system, so i can mix and match package versions at will... With most binary distros its an all or nothing upgrade - if you want new gnome3, you also need to take new x11, new glibc, new gcc etc.

Re:Just trolling (0)

Anonymous Coward | more than 2 years ago | (#36469056)

I'm surprised at the lack of "LOLricerGTFO" comments

Obviously they didn't recompile their browser with -funroll-loops, so it's taking them a few extra cycles to get here.

Re:Just trolling (5, Funny)

Verteiron (224042) | more than 2 years ago | (#36468538)

... and I just finished compiling Firefox so I could submit this story to Slashdot!

*crickets* .. gee, tough crowd.

Re:Just trolling (5, Funny)

Wingman 5 (551897) | more than 2 years ago | (#36468826)

My personal favorite gentoo quote [bash.org]:

<@insomni> it only takes three commands to install Gentoo
<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
<@insomnia> that's the first one

Re:Just trolling (1)

Anonymous Coward | more than 2 years ago | (#36470366)

My personal favorite gentoo quote [bash.org]:

<@insomni> it only takes three commands to install Gentoo

<@insomnia> cfdisk /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6

<@insomnia> that's the first one

Ehh.... not to rain on the joke, but there's nothing in partition /dev/hda1 after mkfsing it. Why so quick to chroot into it? It's missing the stage3 download!

Re:Just trolling (1)

WuphonsReach (684551) | more than 2 years ago | (#36470912)

Which is at least an improvement over the old process... (although emerge'ing firefox that early is a bit of overkill and makes the whole thing fake).

TPM, please? (1, Interesting)

mlts (1038732) | more than 2 years ago | (#36468438)

It would be nice to have a TPM based authentication system as an option. This way, a Linux server can grab a memory image, have the hash of that passed to the TPM, and if unchanged, the boot process continues.

Add a PIN to the process, and the TPM will start denying access after a certain amount of missed tries, so brute forcing a filesystem key isn't going to happen.

This way, someone pulling disks, or booting the server from other media will be unable to decrypt the machine.

Essentially, BitLocker functionality (which admittedly is very good)

Re:TPM - no thank you (0)

Anonymous Coward | more than 2 years ago | (#36468938)

Makes it very hard to replace a motherboard when one dies. All the encrypted disks are useless.

Re:TPM - no thank you (1)

mlts (1038732) | more than 2 years ago | (#36468988)

That is you have a recovery password or keyfile saved off on a USB flash drive. Same procedure with BitLocker.

The TPM is an advantage, an option in addition to the usual typed in passphrase. I wish other operating systems would take advantage of it, and not just Windows, because it brings with it some good security functionality.

Re:TPM - no thank you (0)

Anonymous Coward | more than 2 years ago | (#36469216)

TPM enables treacherous computing [gnu.org]. No thanks.

Re:TPM - no thank you (1)

mlts (1038732) | more than 2 years ago | (#36470538)

In the past, this might have been an issue, but virtually every x86 server and server motherboard out there comes with a TPM present, but disabled and unowned.

Yes, it can be used for DRM, but since the functionality is there, might as well use it for good, and to ensure that a machine hasn't been tampered with, and that the MBR is intact.

Another use for it is a secure keystore for public/private keypairs. For example for code signing, you copy a public/private keypair into it (keeping a backup in a secure, offline place), and if someone compromised the box, they can sign stuff, but do not have access to the keypairs.

Re:TPM, please? (1)

df5ea (227427) | more than 2 years ago | (#36469218)

Yeah, using the TPM would be great. Using a pin instead of a passphrase at most startups would be much less cumbersome.

Obviously you would still need a backup passphrase when you change your motherboard or exhaust the maximum numer of pin tries.

Re:TPM, please? (0)

Anonymous Coward | more than 2 years ago | (#36469484)

I thought about this. A lot.
And without full hardware support for it, in every component, from the keyboard, over everything on the motherboard and the hard disk, to all devices on all buses and even your display, it's pointless. As even a single non-secure (= non-checked) point will cause it all to fall apart.

And that includes EM shielding on a level that doesn't allow reading your keyboard/display from up to 10m away. (I've seed in live.)

Which all assumes nobody gets into the room in the first place.

And if you think you got the perfect system, there's always that last factor: You. Versus that large steel pipe against your head. If you know what I mean. Or just versus a social engineer you think is a nice girl that needs your help. (Disclaimer: The last thing is my job. Ok, I'm not the girl, but I work with the girl. [Don't worry, I do it for good causes.])

Re:TPM, please? (2)

Cato (8296) | more than 2 years ago | (#36471612)

You will probably get your wish, as there are people working on a secure boot using UEFI (modern replacement for BIOS) and the sort of cryptographic integrity validation you are talking about: https://lwn.net/Articles/447381/ [lwn.net] (subscription required, but free from 23 Jun 2011)

This can be used for good (if you own your own keys, you can compile and install your own kernel etc) or bad (if the hardware vendor or OS vendor owns the keys, you have no way to install anything else, i.e. you have a Tivoized system).

Be careful what you wish for... There's a good chance that in a few years' time, new PCs that come with Windows will make it cryptographically impossible to install a new OS. Only if the UEFI allows you to disable this secure boot feature will you be able to do anything beyond Windows.

Linux IMA (Integrity Measurement Architecture) is a separate project, in kernel 2.6.30+, that does similar things within Linux based on TPM: http://linux-ima.sourceforge.net/ [sourceforge.net] - again, the ownership of the keys is critical.

cryptsetup + BTRFS (0)

Anonymous Coward | more than 2 years ago | (#36469764)

BTRFS does check-summing on all data and has automatic data scrubbing. It can also do a RAID-1 of sorts with one hard drive, storing all data twice on the same disk. If it sees a checksum error, it will re-duplicate the good copy. Or you could use two hard drives using BTRFS RAID support.

Lazy-man's encryption (1)

atari2600a (1892574) | more than 2 years ago | (#36470128)

I've been using the eCryptFS built into Ubuntu & touching /fsckcheck in either a recovery or single-user shell every time power gets cut but I'm sure you want something a bit more fancy...

Frendly Help from epSos.de (0)

Anonymous Coward | more than 2 years ago | (#36470272)

Have a Look at :

3 possible options:

Encrypt an SD card.
Encrypt a 7z archive.
Encrypt a virtual folder with EncFS.

Archives are better for backups that are not changing.
EncFS Virtual folders are good for daily use (loss of data happened to some people).
SD cards are good for monthly backups.

Just use FreeBSD (1)

ZorkZero (6507) | more than 2 years ago | (#36470300)

Linux users growing frustrated at the increasingly superior feature set of FreeBSD can take heart that FreeBSD is also open source, and runs all of your favorite software. The adjustment necessary is roughly that of moving from one Linux distribution to another.

OpenPGP (1)

DERoss (1919496) | more than 2 years ago | (#36470624)

Why not PGP (free for non-commercial use) or Gnu Privacy Guard (GPG, free). Both use the OpenPGP method and are interoperable with each other. While neither is open source, the source code for both are supposed to be available to anyone who wants to check the integrity of either application (e.g., lack of back doors).

Re:OpenPGP (0)

Anonymous Coward | more than 2 years ago | (#36471148)

I'm confused - did you intend to say that GPG is not open source, or am I misreading your post? According to the website, it's Free Software released under the GPL.

christian louboutin sale (-1)

Anonymous Coward | more than 2 years ago | (#36470660)

Also Sale Famous Christian Louboutin outlet,Christian Louboutin bridal,Christian Louboutin wedding Order Now Please and Save More!Christian Louboutin wedding shoes are bridal necessities,if you like just take it!Christian Louboutin outlet best quality shoes with high technical and fashionable shape!
http://www.christianlouboutinsalen.com .For example: Christian Louboutin gold leather Libelle sandals sale [christianl...nsalen.com].

Debian kfreebsd (1)

GPLHost-Thomas (1330431) | more than 2 years ago | (#36471042)

If you liked FreeBSD, the kernel, but didn't like the userland, why don't you take the good of both worlds, and install Debian kfreebsd, which is Debian, but running the FreeBSD kernel?

University of Wisconsin - Madison (1)

fnj (64210) | more than 2 years ago | (#36471054)

This [wisc.edu] looks like a project to address adding checksums in the md(4) Multiple Device layer (not ideally named, because MD is perfectly usable on a single drive). Because MD is a layer under the filesystem, any filesystem is supported. They only support RAID4C (checksumming RAID4) and RAID5C (checksumming RAID5), though they show how to implement it on a single volume, albeit with a large performance penalty.

There is an excellent paper which analyzes the integrity issue you are trying to address.

I wish this would get into linux kernel mainstream.

Messes up alignment (1)

gweihir (88907) | more than 2 years ago | (#36471326)

The checksums need storage space. So you either have to reduce usable block size or use extra sectors. Both options mean you lose the 1:1 block mapping that both dm-crypt and LUKS (the latter with an offset) provide. This can cause all sorts of problems, unless the file-system layer is also optimized for it and therefore dm-crypt and LUKS delegate any such checking in addition to what the disks themselves already do to the file-system layer.

But the second thing is this: You have to basically trust your disk anyways. You can also trust your disk in most cases, as the rate for an unrecognized read error is basically low enough that these will not happen in practice, unless the disk is seriously damaged (e.g. defective buffer RAM). So unless you use extremely large amounts of storage (say, > 500 disks) and extremely high integrity needs, I would suggest you are barking up the wrong tree and want something here that you do not in fact need.

Re:Messes up alignment (2)

dutchwhizzman (817898) | more than 2 years ago | (#36471686)

Not if you store the sum in another block. Look at how ZFS does it, very sweet because data stays data and the metadata contains the checksum. I could copy and paste the details here, but you could find those by yourself.

You should never trust your disk. The amount of unrecognized single sector failures on modern disks is so big, that with a >90% probability, at any given moment, a stripe/raid with four 2TB disks will contain at least one of them. All professional grade storage systems have disc scrubbing and checksumming in place just because of this.

The extreme large amounts of storage you are talking about was valid when disks were 4GB. Modern discs have the same error rate as then, per byte stored. All you do is have these 500 4GB discs consolidated on a single disk of 2TB. Same amount of sectors that can get broken, same actual amount of broken sectors.

Re:Messes up alignment (0)

Anonymous Coward | more than 2 years ago | (#36472430)

The error rate of a disk read depends on the data density on the platter and the platter quality. If you compare an old 4GB disk to a new 2TB disk, and they have the same number of platters, and same platter defect rate per unit area, then the read errors per unit data on the 2TB disk will be approximately 500 times LOWER than that of the 4GB disk.

ZFS encryption (2)

Cato (8296) | more than 2 years ago | (#36471504)

ZFS has very good per-block checksumming and many other features, and now has encryption support, which should be in OpenIndiana (the non-Oracle fork of OpenSolaris): http://milek.blogspot.com/2010/10/zfs-encryption.html [blogspot.com]. ZFS is a combination of volume manager (like LVM), software RAID and filesystem. Here's a useful HOWTO on setup: http://hardforum.com/showthread.php?t=1573272 [hardforum.com]

Unfortunately ZFS support in Linux is userland only due to licensing issues. It may not have encryption yet either - however you could run TrueCrypt on top of a ZFS volume (like an LVM logical volume), bypassing the ZFS filesystem part.

Re:ZFS encryption (0)

Anonymous Coward | more than 2 years ago | (#36471712)

Not any more. ZFS runs in kernel now, see http://zfsonlinux.org/. Give it a try, it looks quite stable and usable to me on Scientific Linux 6. I can watch a movie on XBMC while scrubbing 1TB mirror volume on a 4 year old box.

Do it the other way around (0)

Anonymous Coward | more than 2 years ago | (#36472840)

It makes more sense to run ZFS ontop of an encryption solution (TrueCrypt, LUKS, whatever you like) to have the fun parts of ZFS available (filesystems, snapshots, compression, dedup).

SHA is a Hash, not a Checksum (0)

Anonymous Coward | more than 2 years ago | (#36472406)

Just wanted to mention that...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account