Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Encryption HOWTO

Posted by CmdrTaco on from the why-not-learn-something-new dept.

lazyecho writes: "How to set up a Linux 2.2 system to use encryption in both disk and network accesses. This document describes how you can use the International Kernel Patch and other packages to make hard disk contents and network traffic inaccessible to others by encrypting them." Hey, your box is stable, why not mix it up a bit? I'm not a security nut, but this strikes me as a fun one anyway.

27 of 60 comments (clear)

  1. Very useful law survey cited in HOWTO by Vassily+Overveight · · Score: 2

    Wow. The HOWTO contained a link to a summary of crypto law thruout the world. Quite a resource, and definitely something that anyone contemplating this technique ought to be aware of. Here's the link.

    --

    "If I have seen further than other men, it is by stepping on their glasses." - Michael Swaine

  2. Re:nice.. but remember the rest.. by Fred_A · · Score: 2
    encrypting everything is useful.. but remember anyone can gain access to your machine with a large caliber handgun and easy access to your head.

    That's not the point. I'm looking into filesystem crypto for my laptop, not for fear of them (insert your favorite governmental boogeyman here) but because the thing holds my private key, access info for a bunch of remote systems, private information, email that can be potentially sensitive for my clients, etc.

    So if I loose the thing, I don't want that data to be accessible to whoever stumbles upon it.

    Now for encrypting your home box, unless you live with the hacker from outer space or work for Echelon, there isn't much point...

    --

    May contain traces of nut.
    Made from the freshest electrons.
  3. Re:What I think I'd like to see... by Billy+Donahue · · Score: 2

    The other is that for many public-key systems (if not all?), you'd need one version of each file for *every* private key meant to decrypt it, which in some settings might be a bit much if one runs into problems assigning groups.

    Actually, the message is encrypted with a session key, and the session key and a message hash is encrypted to a public key and tacked onto the message.. You can tack as many encrypted session keys and hashes to the message as you want, they aren't big at all... The bulk of the message is encrypted with a single session key.

    --
    -- The Funk, The Whole Funk, And Nothing But The Funk
  4. Re:nice demonstration of downside by cr0sh · · Score: 2

    I don't know about you, but this guy definitely wasn't too bright. He needs to take a tip from OC'ers, and learn to dump the heat.

    Where, you might ask?

    Well, if I was growing MJ, and wanting to dump the heat in the least expensive, but most innocent looking way, I would build myself a large swimming pool, preferably with one end for diving (>10 feet deep). After digging the hole (but prior to the cement pouring), I would lay copper tubing coils all over the bottom, bringing the taps up near the pumps. I would set up an extra pump, and a heat exchanger to wherever my growing area was at, insulate the hell out of everything (to make sure heat doesn't escape through the walls or ceiling), install some nice air circulators to circulate the air through the heat exchanger, then pump a brine/antifreeze mixture through the whole thing. I might even go so far as to build a "spa" to monitor ambient vs. cooling pond (for that is what the pool would be) temperatures.

    Heh, who'd of thought there would be a need to put a heatsink on your MJ growing op?

    I support the EFF - do you?

    --
    Reason is the Path to God - Anon
  5. CmdrTaco officially insane by Eil · · Score: 2


    QOTD:
    Hey, your box is stable, why not mix it up a bit?

    HAHAHA! Famous last words, Taco!!

  6. Sometimes that can be a disadvantage. by Paul+Crowley · · Score: 2

    "That's not the real key, that's the duress key! Give me the real key!" *thwack*

    "But Boris, that *was* the real, final key! I swear there aren't any other keys for that drive, I swear!"

    You can't have it both ways...
    --

    --
    Xenu loves you!
  7. Re:nice demonstration of downside by theonetruekeebler · · Score: 2
    You got caught with evidence of criminal activity in plain sight, and I'd be glad. Unreasonable search and seizure laws are designed to protect people against government meddling and other abuses
    Speaking of unreasonable searches, the US Supreme Court is now considering Ky llo v. U.S., 99-8508 , which will decide whether police helicopters hovering over your house pointing an infrared sensors at your roof constitutes a search or if they can just do it for the hell of it.

    I'm just mentioning this because it's amazing how many technological innovations become the tools used to invade privacy. I mean, if it's okay for them to point an infrared sensor at your roof, is it okay for them to point a laser interferometer at your window to see if anyone inside is talking about drugs? It's non-invasive, right? They didn't actually enter your premises, right?

    All this ties in so well with the EU/US anti-privacy treaty in the works.

    --

    --
    This is not my sandwich.
  8. Re:StegFS sounds awesome... But... by jeti+ · · Score: 3
    Isn't there a way to have some combination of encryption and compression so that a file has two keys, one returns benign data and the other returns the real contents?
    Using two different steganographic algorythms (or at least keys) in a same file? You would only need to choose the bits to hide the information so that they won't overlap.

    An oversimplified example would be that if you hide information in an (uncompressed) .wav file, you store information A to the lowest bit of the left channel and information B to the lowest bit of the right channel.

    For this kind of operation you should propably choose a big file with plenty of 'insignificant' bits to choose (like MPEG video) so it would be easy to explain why you didn't use every possible bit to store data.

    --

    // /

  9. Great for Laptops / Handhelds by Xunker · · Score: 5

    This is a great thing for those of use that use laptops on a daily basis and hope to use use *nix-based handhelds soon... at least here in the USA... to keep over-zealous law-enforcment officials at bay;

    Now, IAMAL[?], but here is how I got it explained to me: Items on your person fall under the dictates of law governing search and siezure. If you have a cabinet in your home, the police are allowed to search is if they have probable cause; but if you have a safe in you your home, you are not required to volunteer the combination to it without a subpeona. Goes the same for passwords and crypto, too, AFAIK. They can put me in the squad car, but until they get a court order, I don't have to tell them the password to my PDA or my GPG/PGP secret key passphrase.

    This is a good thing, because an over-zealous officer could start dinking around on you laptop and find some incrimitation evidence (violating S&C Law), but tell the judge that he found 'by accident'. Who is the judge going to believe? But if you have it all locked up tight, nothing short of a circuit court judge can force you to unlock it.

    And please not my gratuitous use of the phrase 'over-zealous'. The VAST majority of law officers are decent human beings - its just those choice few emmy-award winners that makes everyones life hell.

    At the very least put a pasword on your PDA, laptop, and modified-laptop-car-MP3-Player. Especially the MP3 player -- Ms. Spears would be so pissed if she found out I downloaded all 50 remixes of "I'm a closet dyke" off Napster :)

    --
    Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
  10. Crypto Progs by digitaltraveller · · Score: 3

    There is an excellent open source Winblows encryption program called scramdisk. (www.scramdisk.clara.net) I believe they are porting it to linux. The nice thing about it is it mounts a file as a partition, and it's simple enough to back up that file so you don't have to worry about data integrity issues preventing you from decryption. I haven't read the howto yet but I hope it works the same way.....Rather then actually partitioning off part of the disk geometry.

  11. The Ultimate in Hard Drive Encryption by nihilogos · · Score: 3

    Even the purpose of this software is cunningly disguised.

    Masquerading as a set of utilities for mounting an ext2 partition from MS-DOS, Ltools is guaranteed to make your linux filesystems completely inaccessible to anybody.

    One of the most glaring insecurities in most disk encryption systems is the user themselves. They may simply be threatened with hot lubricating jelly and will reveal the all important encryption keys. Not so with Ltools - even the user is unable to retrieve the information once it is encrypted.

    Simply install the Ltools package on your windows partition and then type 'lmkdir etc'. I did this yesterday and believe me, there's no way anybody's accessing my root filesystem!

    --
    :wq
  12. De-crypt/delete option by dazol · · Score: 2

    What about a de-crypt/delete option? i.e. you encrypt the drive. There are 2 different commands (or command arguments). One just decrypts the data. The second, decrypts the data, but while doing so, deletes/rewrites a bunch of times the drive/data. That way, if you have to give your key to someone, or they ask you to decrypt it, you can without worrying about exposing sensitive data, because it is effectively gone. Is there a reason that wouldnt work?

    1. Re:De-crypt/delete option by rcw-work · · Score: 2
      Make a plausible (legal) replacement for what was encrypted, use chaffing to place both items in the same file along with a bunch of other random garbage, and when they ask for the passphrase, give them the one that decodes the file to the birdwatching tapes you've been recording.

      If you do it properly they won't be able to prove there's any other data there. There's not much to tell them it's 32x chaff instead of 64x chaff.

  13. Re:What I think I'd like to see... by Stonehand · · Score: 2

    Offhand, I'd have to wonder how the keys themselves would be stored/accessed, as that might be the weakest point -- perhaps a magstripe card reader? Or -- is rice paper scannable? (Heh.)

    The other is that for many public-key systems (if not all?), you'd need one version of each file for *every* private key meant to decrypt it, which in some settings might be a bit much if one runs into problems assigning groups.

    Root could easily be given access under such a system by always having one copy encrypted using the root key, or alternately, key escrow, if it were critical that root have such (Not necessarily, say, for an ISP admin, but perhaps for a system with classified material...).

    --
    Only the dead have seen the end of war.
  14. Re:What I think I'd like to see... by TheMeld · · Score: 2

    "The other is that for many public-key systems (if not all?), you'd need one version of each file for *every* private key meant to decrypt it, which in some settings might be a bit much if one runs into problems assigning groups"

    This isn't how public-key crypto is usually done, and nor is it at all how Leknor suggested it. You generate a random key with which you encrypt the file. One key for the file! Then you take that key and encrypt it with the public key of the file's owner and the file's group (each group would have a public/private key pair). For each group on the system, you encrypt the group's private key in each of its member's public keys.

    Then, when a user logs in, s/he can decrypt the decryption keys for files s/he owns, and the private keys for the his/her groups. With the group private keys, s/he can decrypt the decryption keys for files that s/he has group access to.

    So the overhead is in storing a public key for every user and group, the private key for each group encrypted with the public key of each of its members, and for each file, two copies of the decryption key for that file, one encrypted in the owner's public key, one in the group's public key.

    So you lose a couple kb per file, and (very generously) a meg for the user/group database if you have a system with several users. A system like sourceforge which has zillions of users would have several megs of overhead, but such a large system isn't likely to notice that with it's many many gigs of disk space.
    -Matt

    --
    -Cheetah
  15. Useful for /home/ME by BadlandZ · · Score: 2

    This really isn't too new, but it is cool for smaller scale uses. You can just encript one partition, and of course, it's nice to have that partition be your own personal /home/myusername ;-)

  16. Never gonna be as good as thermite. by bnolan · · Score: 3
    When the NSA take my machine away - I'm not gonna be puttin' no trusting in no Blowfish / RSA1024 / whathaveyou.

    Nope - never gonna feel truly safe until I got a big block of thermite tied to my hard drive and the dead-mans trigger in my left hand. :)

    Win32 Napster Client.

    --

    :wq

  17. WOW! by clinko · · Score: 4

    This is great Now I can spend hours encrypting everything I own. First I'll Start with all my disks then i'll do my network and then i'll realize that my life is an empty shell.

    1 year later:
    Why god do i have to encrypt everything? WHY!?
    I remember when it all started. It started with the disks, then i lost my job, then i lost my girlfriend, and i lost what life i had.

    DAMN YOU Linux Encryption HOWTO! DAMN YOU STRAIT TO HELL!!!

  18. No need thanks to the DMCA by Anonymous Coward · · Score: 2

    Why bother? Isn't any linux box password protected by a salted DES-based crypt function? Accessing the hard-drive contents -- even by physically transfering the hard-drive to another machine -- would be a clear circumvention of the access control measures which, as you well know by now, is illegal under the DMCA.

  19. Data Integrity by Th3+D0t · · Score: 4
    I would install an encrypting filesystem but for concerns of data integrity, performance, and validity.

    What if my filesystem were to go down? I could never recover my data. In addition performance would be hindered severly by the blocking overhead of the encryption and decryption (which is essentially the same exponential operation backwards and forwards).

    Until someone develops a hardware solution, I have to say, "no thank you."
    ---

    --
    I am the dot in slashdot.org
    1. Re:Data Integrity by avorpa · · Score: 4

      A few objections:

      1: The encryption works at a different level from the filesystem. If the filesystem gets corrupted, you can still decrypt the data, and you will be in the same position you would be if you didn't use encryption at all. Of course if you forget your password you'll never get the data back, but thats the point.

      2: And the blocking overhead? All the algorithms in the patch have 64 or 128 bit block size. This is far less than the size of a disk block, so i wouldn't be worried.

      3: There is no exponential operation. You are thinking of RSA, which is a public key algorithm. Public key algorithms have longer blocks and are slower than private key ones. They are necessary when you want anyone to be able to encrypt, but only you to be able to decrypt. Seeing you don't need this for disk encryption, private key algorithms are more appropriate.

      4: There are many hardware solutions, but they are generally designed for network encryption. Presumably you could write drivers to get them to do the computation for the disk encryption. Anyway, the processing isn't the main thing killing performance: twofish runs in 17 cycles per byte. The performace killer is that it works through a loopback device, which makes readahead and caching less efficient (i think thats the problem, but i'm not entirely sure about this).

  20. In the FreeBSD ports directory by Brew+Bird · · Score: 2

    I know this has been aroud for an increadibly long time...

    ftp://research.att.com/dist/mab/cfs.ps

    and I think they have also built a kernel module to do it at the kernel level (cfs looks like an NFS file mount, to get around all that nast kernal stuff), but I don't have the time to go hunting for it...

    Yet another 'feature' that is Brand New(tm) now that Slashdot has 'discovered' it.

    1. Re:In the FreeBSD ports directory by Brew+Bird · · Score: 2

      Sorry the blowfish encrypted swap filesystem is in OPENBSD...

      Also check out TCFS http://tcfs.dia.unisa.it/group-sharing.html

  21. StegFS sounds awesome... by Booker · · Score: 4
    I love the idea of StegFS -

    StegFS is a Steganographic File System for Linux. Not only does it encrypt data, it also hides it such that it cannot be proved to be there.

    You know it's hard core when the docs refer vaguely to the ability to keep data secret in the face of torture. 1024-bit public-key encryption is all well and good, but threaten me with a glass rod, and I'll hand that key right over. Plausible deniability is where it's at! :)

    ---

  22. What I think I'd like to see... by Leknor · · Score: 3
    I'm not a crypto person but why not something like this:

    Each file is encrypted with a key that is then encrypted with the public keys for the user and group and maybe unencrypted if everybody has privilages.

    Then when a user logs in his private key is decrypted and the private keys for the groups he belongs to is decrypted with his private user key.

    Then with all the private keys the user can decrypt the keys that decrypt the files.

    I'm sure there are holes in this, so please tell me. All I know is what i've learned from reading about PGP, SSH, and CSS (hope I don't get sued for learning) and that isn't much. The only drawback I see is maybe a file could be out of the reach of root, but that isn't a drawback IMO.

    Leknor

  23. To take this inverse by Felinoid · · Score: 3

    One day my Boss takes a look at my computers hard disk.
    Yeah sure it's secure but the disk isn't encrypted and I'm really lucky to have a boss who knows Unix.
    Oh and I keep a Linux CD handy in case I need to restore my computer from a nasty crash.. how smart of me...

    Apparently my Boss dosn't share my intrests in techno advocacy.. the DVD DeCSS directory means.. I'm out of work...
    Oh well...
    So I get home.. my girl friend isn't quite so tech savy as I am but I'm allways teaching her stuff...
    Hay she learned a new trick on her own today..
    I mean now that I'm out of work my computers at home.. so she started tinkering around..
    I never did give her much access so she picks up the cd..
    the dam porn directory...

    Now I have no girlfriend...

    Mom wants to use the computer.. she's pritty tech savy... learnned CP/M way back and had access to a PDP11/70 when I was still a kid...

    But sadly all her equipment is obsolete... Commodore Pets.. Apple IIs.. She wants to use my Linux box while I'm out looking for work...
    Thats ok.... hmmmm

    Encryption HowTo... yeah Mom would he happy to have her network connection encrypted.. (I'll just encrypt all my personal files while I'm at it)

    Please note.. the above is fiction.. my boss dosn't look at my computer and I can't get my GF to even consider Linux...
    I don't have a porn directory and I keep DVD DeCSS on a ZipDisk...

    --
    I don't actually exist.
  24. Local Disk encryption by DaveHowe · · Score: 2

    I am leaving my local encryption until the imminent release of Scramdisk for linux - that way I will be able to open the *same* encrypted data under Win9x too. Currently, I can only really do that with PGP....
    --

    --
    -=DaveHowe=-