Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Encryption Operating Systems Security BSD

GBDE-GEOM Based Disk Encryption on FreeBSD 210

Posted by michael from the as-long-as-men-are-capable-of-evil dept.
BSD Forums writes "The ever increasing mobility of computers has made protection of data on digital storage media an important requirement in a number of applications and situations. GBDE is a strong cryptographic facility for denying unauthorised access to data stored on a 'cold' disk for decades and longer. GBDE operates on the disk(-partition) level allowing any type of file system or database to be protected. A significant focus has been put on the practical aspects in order to make it possible to deploy GBDE in the real world. FreeBSD's Poul-Henning Kamp says in an email to freebsd-current that he has uploaded this paper and slides which he presented at BSDcon 2003, California, USA."
This discussion has been archived. No new comments can be posted.

GBDE-GEOM Based Disk Encryption on FreeBSD More

GBDE-GEOM Based Disk Encryption on FreeBSD

Comments Filter:
  • When they have mascots like this [hope-2000.org]?

  • good idea (Score:2, Interesting)

    by vonFinkelstien ( 687265 )
    Sounds good. Is this what Apple is basing FileVault on or have they took another open source project for that or built it from scratch?

    For those of you who do not know. FileVault is data encryption for Panther (Mac OS X.3).

    • FileVault is an encrypted disc image that is automatically mounted when you login.
      It uses AES encryption (128 bit)
      Its been written within Apple, using existing Apple technologies.
      Using Disc Utility you can do the same on Jaguar, except Panther and FileVault make it very easy to do....

  • CD-ROM encryption (Score:5, Interesting)

    by avleeuwen ( 697047 ) on Sunday September 28, 2003 @04:09AM (#7076313)
    One of the cooler features that come with GBDE is the fact that you can encrypt CD-ROM images. This makes for a very secure way of getting someone a lot of sensitive data. A patch was recently posted on the current@ mailing list to allow this.
    • Whatever happened to just fucking gpg -c a tar ball?

      How many times do you write to a CD-R?

      This seems like a "solution to a problem that doesn't exist".

      As for Harddisk encryption... that's just stupid. Of the 250,000 files on my disk, 100 of them are private. Why should I waste time/space to secure encrypt the rest of my disk when I could careless if you can read my files [when you break into my house and use my computer no less].

      Tom

      • (LOL - I thought I recognised the attitude from sci.crypt ;)).

        This seems like a "solution to a problem that doesn't exist".

        Really? Well some companies (PGP, SecurStar, Bestcrypt, SafeBoot etc) make a lot of money out of selling commercial products that perform OTFE. The LOOPAES / CryptoLoop mailing lists seem to be pretty busy too.....

        Don't confuse "Tom doesn't have a need for this kind of encryption" with "nobody needs this kind of encryption".

        • Really? PGP makes lots of money? That's why the project has been sidelined forever and GPG is basically dominating?

          Oops...

          I don't doubt people need it, I just think most users who do use it are poorly informed on security related issues. Encrypting your entire disk because you may want to keep 3 files private is a huge waste of time and memory.

          Tom

          • Re:CD-ROM encryption (Score:2, Informative)

            by avleeuwen ( 697047 )
            No, you got that wrong. GBDE can also encrypt a partition. This means you create one partition when installing your system that you will encrypt, where you keep your private files. This makes it a lot easier to use than any application level interface (be it PGP/GPG/whatever). This is also explained in the paper, but I guess you didn't read that before commenting.
      • As for Harddisk encryption... that's just stupid. Of the 250,000 files on my disk, 100 of them are private. Why should I waste time/space to secure encrypt the rest of my disk when I could careless if you can read my files [when you break into my house and use my computer no less].

        Perhaps because you'd rather have your adversary spending time trying to decrypt the innocuous stuff, instead of being able to home in on your 100 private files?

      • 1. This is much more important on a laptop where someone can just walk off with your whole computer.

        2. If you encrypt a whole drive, then all you have to do is throw your important/private files onto that drive. Once you have it going, it's a lot easier than individually encrypting your files.
  • does gbde work with vinum yet?

  • MI6 (Score:5, Funny)

    by Cookeisparanoid ( 178680 ) on Sunday September 28, 2003 @04:31AM (#7076355) Homepage
    This is great news for all those M16/CIA/etc agents how leave their laptops in the back of taxis!

  • Better performance numbers? (Score:3, Interesting)

    by BlueFall ( 141123 ) on Sunday September 28, 2003 @04:50AM (#7076379)
    There are some nice ideas and good thinking here, but does anyone have a link to more interesting performance numbers? I'm curious how well this would work on a workload that was both intense and non-sequential.

  • And this is news how? (Score:1, Informative)

    by Anonymous Coward

    1) GBDE has been available for months. Had you talked about GEOM-Gate, now that would have been interesting.

    2) Poul-Henning suffers from extreme NIH complex. This crypto support has been in OpenBSD for 2 years.

    3) Do you think he will let anyone touch his code? He didn't for phkmalloc and that piece of shit called devd, what makes you think he will now?

    Poul-Henning is probably the most arrogant person I've ever seen. He has negatively influenced FreeBSD in a way I cannot even describe. Now go and m

    • This crypto support has been in OpenBSD for 2 years

      I thought that was just for swap partitions. Correct me if I'm wrong.

    • Excuse me, what's wrong with P.H. not letting other people touch his code? I mean, it works to some extent. What be the reason to make changes?

      I have heard that with the DragonFly-BSD project, there is also coming a patch to Poul-Henning Kamp, which is said to bring him to a higher level of co-operation.

    • Gee, I missed this gem :-)

      Hi Alan, do I know you ?

      OpenBSD has not had any crypto support like this ever, and as far as I know, no other Open Source OS does either.

      I will admit that OpenBSD has had some crypto support, but it suffers from a lot of shortcomings, in particular in the usability area. (try to change your password for instance).

      I don't know why you think I won't let people change phkmalloc, it's under beer-ware license, so go right ahead. In fact I'm working with an OpenBSD'er right now

  • How is this like rubberhose?
    • Is the rubberhose project still alive?

      I stumbled across the page [rubberhose.org] a feew weeks ago and found it intresting, but it seemed abandoned. (Availible to linux kernel 2.2 etc). Altso the page has disappered, google cache [216.239.59.104].

      Has anybody tried to use robberhose, any experiense to share?

    • Re:rubberhose (Score:4, Insightful)

      by kasperd ( 592156 ) on Sunday September 28, 2003 @06:55AM (#7076572) Homepage Journal
      How is this like rubberhose?

      AFAIK rubberhouse works on the filesystem layer, while what is described here work on the block layer. That actually means you can easilly use the two on top of each other (assuming they are available for the same OS). Some of the security properties rubberhose aims for are impossible to do on the block layer. OTOH doing encryption on the block layer is simpler than doing it on the filesystem layer, and you are free to put whatever filesystem you prefer on top of that. Of course even encryption on the block layer can get complicated if you want to make it as secure as possible. Maybe performance can be improved by doing encryption in the filesystem, but proving security gets really tricky.
    • Hmm, I thought rubber hose was a term for decryption hardware/techniques that work against strong crypto?

      A popular specific method:
      WhackWhackWhackWhack
      Intermediate results:
      OwOwAAAghAiyeeeNoo!Aah!

      Repeat till key is obtained.
      • I thought rubber hose was a term for decryption hardware/techniques that work against strong crypto?

        It is also the name of a filesystem encryption supposed to be resistant to this kind of attack. The victim provides you with a password, and you can decrypt the filesystem and find a number of files. There will be some free space, which is filled with random bytes. There could be another password, which would reveal that some of the aparantly empty space contains more encrypted files. And so it goes on. No
        • Unfortunately, unless that system were modified to make it's very use deniable, the name would become all too apt as the target of the investigation is beaten to near death until something sufficiently incriminating is found--and maybe after, since there could always be something worse in the free space.
          • and maybe after, since there could always be something worse in the free space.

            That would remove every incitement to tell them anything, no matter how much you tell them they could think you are hiding something.
            • But if the use of the system could be denied to begin with, there could just be a disk with innocuous data and no "rubberhose" container to start spelunking in to begin with (as far as the adversary knows). Of course, there's then the issue of how that 16 GB of uncompressable text got there to begin with . . .
        • "No matter how many passwords you have, there is no way to know, if the rest of the space is free space with random bytes or there is another one."

          Translation: No matter how many passwords you give to the hose-wielding cryptanalyst, there is no way to know if the beatings are ever going to stop.

          Steganography + straight headerless crypto could be better. I think it's better to figure out a way to store data in MP3s (hard because lots of less audible bits are thrown away). e.g. squeeze 50MB of encrypted dat
          • A better cover would be a hobby/job as a photographer.

            Yep, store all original uncompressed images (or lossless compressed). That is a good idea, because if you want to manipulate the images later, you want to maintain the quality as long as possible. Of course you can hide something in the least significant bits. And by hashing the bits you are going to overwrite you also have a great random source for your probabilistic encryption.

  • as a strong hash function.

    I thought this was a bad idea, since RSA is non probabilistic. When used as a hash, you've got neither semantic security nor indistinguishability.

    Didn't read what they used the hash for though.

    • Re:They say they're using RSA.. (Score:1, Informative)

      by Anonymous Coward
      I believe it's a typo in the paper. The actual
      hash function used is SHA, not RSA (see below
      in the same paragraph that mentions RSA)
    • I thought this was a bad idea, since RSA is non probabilistic.
      A hash function is not supposed to be probabilistic, a hash function must be deterministic, otherwise it wouldn't work. Of course using RSA for hashing is a bad idea not only because of performance, but also because RSA is not a hash function.

      When used as a hash, you've got neither semantic security nor indistinguishability.
      Semantic security is a concept used about encryptions not hashes. To get semantic security an encryption needs to be p

    • Nah, that's a typo. Read further into the paper and you can see they mean SHA2/512 rather than RSA2/512.

  • Interoperability issues (Score:5, Insightful)

    by chrysalis ( 50680 ) on Sunday September 28, 2003 @05:36AM (#7076440) Homepage
    This is not a new idea.

    OpenBSD (vn* devices) and Linux (crypto-loop) have this for years. NetBSD also has it. Windows XP also has it.

    Now FreeBSD introduces yet another implementation of the same thing.

    This is great, but what about interoperability?

    Right now, all operating systems I can use encrypted partitions, but the way they do it is different on every system.

    If I encrypt my USB memory key on FreeBSD, I won't be able to use it on Linux. Even if the actual file system is the same, even if the encryption algorithm is the same.

    This is illogical. Encrypted partitions are nice for small, portable devices, that you can plug on various hosts running various operating systems. That's the theory. But because everyone reinvents the wheel, you can't do that. It won't work.

    Now that we have filesystems that almost any operating system out there has support for (ext2/ext3 and vfat), maybe it would be nice to use a common format for the encryption layer.

    • Re:Interoperability issues (Score:1, Informative)

      by Anonymous Coward
      GBDE is *not* the same as the other solutions
      you mentioned, it is much more secure. Please
      read the paper for details if you want to know
      why.
      • Maybe it is better, faster, stronger.

        But it doesn't work outside a development version of one specific operating system.

        So it is just as useless as other solutions for portable storage devices that you want to plug into friend's computers.

    • Windows XP also has it.

      Only with the addition of 3rd party products (ScramDisk, PGPDisk, DriveCrypt, BestCrypt etc) - the build in encryption ISN'T drive encryption, but file encryption...

    • OpenBSD (vn* devices) and Linux (crypto-loop) have this for years. NetBSD also has it. Windows XP also has it.

      No, cryptoloop in linux can not do the same. Cryptoloop can encrypt, but you can not change password. Luckily there are other ways to do that, PPDD [linux01.gwdg.de] which appears to be using the same princip of storing the real key on the disk, though encrypted with the password. The same princip a friend and me is using in our development of a device-mapper target, deadline is 1. october.
      Not having any more know

    • This is great, but what about interoperability?

      While I agree interoperability is important, there are some more important problems to solve first. You mention the Linux cryptoloop implementation. But cryptoloop doesn't even interoperate with itself. In earlier versions you could copy the file used for actual storage to a different locations, and it would get unreadable. That was a major problem, because it was bound to eventually cause data loss. Newer version has addressed this issue. During the last fe

  • That is very interesting (Score:4, Interesting)

    by kasperd ( 592156 ) on Sunday September 28, 2003 @05:42AM (#7076452) Homepage Journal
    I have been working on article on disk encryption though it is not quite ready to be published yet. I didn't know anybody else was working seriously on this. I know about cryptoloop in Linux. It is bad, but not the worst I have seen described. It is nice to finally see somebody but me realizing that disk encryption is not as simple as those implementing it think. I don't know how the more "professional" products work. What I have realized is, that good disk encryption has an overhead on disk usage. Those "professional" products I have seen just a few details about doesn't have for too litle overhead for good crypto. The system described by the article only protects cold disks, no protection at all for hot disks. What I describe in my own article actually has some protection for hot disks, not much protection though, because the hot disk naturally limits the protection that is possible.

    • "I know about cryptoloop in Linux. It is bad,"

      Why is it bad? I don't see any sensible arguments that support your claim.

      Go away, troll.

      • Why is it bad?

        It use sector numbers as IV.

        • It use sector numbers as IV.

          Granted, that's not great (but the risk is mitigated by using a random encryption key anyway). Note that GBDE uses a static (all zero!) IV - even worse!

          • Granted, that's not great (but the risk is mitigated by using a random encryption key anyway).
            The key used by cryptoloop is just the hash of the password. But being random or not is not really the point here. The point is, that it is the same key being used for every sector on the disk, and every time that sector is being written.

            Note that GBDE uses a static (all zero!) IV - even worse!
            I must admit I didn't read all of it yet. (I'll print out the article tomorrow at the university). I have been thinki
          • The GBDE doc says they use a pseudorandom key to encrypt a sector so they can get away with a zero IV.

            Haven't figured out why GBDE needs the complex scheme of cherry picker, PRNG and so on.

            BTW what did scramdisk use for IV?
          • confusion!

            I thought the whole idea about loopback devices was that you abstracted away from the underlying medium, so that you could store the image in a file. So, I'm confused as to where the sectors enter into it.

            To quote the article, they say that loopAES is not block-level encryption. I don't understand how it could be anything else.

            help!
  • Ok, when is this going to be ported to Linux kernel?

    This sure looks better than my current somewhat kludgy scheme of using Bestcrypt to mount different virtual drives.

    And I just received my USB cryptoki token. Now, combine this disk encryption scheme, a good token for the keys, a good BIOS encryption (anyone has any info this?), the only thing left to do would be working on my good old tin foil hat now :)

    Boy, you gotta love this kind of cross-polination among open source projects.

  • of this system, compared to others, is that it is so low level as to be filesystem agnostic.

    As long as AES is considered to have decent security, this system could be used.

  • Random comments... (Score:5, Interesting)

    by ssimpson ( 133662 ) <slashdot@samsim[ ]n.com ['pso' in gap]> on Sunday September 28, 2003 @06:59AM (#7076579) Homepage

    (Full disclosure: I've been involved with the Win32 Scramdisk [samsimpson.com] project in the past)

    Hhhm, this is pretty interesting. I am not aware of any other disk encryption program (Scramdisk, DriveCrypt, LoopAES, PGPDisk, BestCrypt etc) that offers sector remapping. It's useful because it prevents standard disk structures from being exploited in a known plaintext attack (note: with current knowledge, this is only a theoretical weakness with AES anyway).

    Apart from that it looks a pretty standard On-The-Fly-Encryption (OTFE) system. It does appear to be slightly more complex than most programs, but this is offset by the peer review from (at least...) two very well respected cryptographers - Dr David Wagner [berkeley.edu] and Lucky Green. I am not aware of any of the other OTFE systems being reviewed by anyone half this competent.

    Last paragraph of 6 says "RSA2/512" should read SHA2/512.

    I'd personally be worried about the use of a static (zero!) IV. I know the key is random, but.....Oh well, if Dr Wagner has peer reviewed it then this can't be much of an issue.

    From the paper: "A truly paranoid setup would leave the computer con- figured to boot the Windows system by default, and locate the GBDE data in such a way that it would be destroyed by the act of doing so."

    It's likely this wouldn't work - the first thing a half-competent adversary would do is image all disks in a system before booting....It's forensic 101.

    • [I am not aware of any of the other OTFE systems being reviewed by anyone half this competent.]

      SecurDoc at winmagic.com was reviewed by Bruce Schneier of Counterpane.

      By the way does anyone know if any of these disk encryption systems keep bit flipping (not function) the key so that reading a "hot" dram is a less effective hardware attack ? Or even better any product which encrypts dram like proposed in :http://www.w4g.org/ee565.html
    • I'm not really convinced by the cryptography in this paper. It's good that Wagner has read it but I wouldn't interpret that as meaning he's put his seal of approval on it.

      Incidentally, I presented a paper on disk sector encryption at FSE 2000, you can read it here:

      http://www.ciphergoth.org/crypto/mercy/
  • Lots of operating systems have had disk-at-a-time encryption. You can already get it for Windows, but that was apparently not good enough to have that PPT junkie use it either.

    Disk-at-a-time (or file-system-at-a-time) encryption just doesn't seem to be convenient enough. Most files simply do not need to be encrypted, and the risk of losing an entire disk due to bugs or losing the pass phrase is just too high, as is the computational cost. People need to be able to decide on a per-file basis what gets enc

    • Re:disk-at-a-time encryption no good (Score:4, Informative)

      by airConditionedGypsy ( 703864 ) on Sunday September 28, 2003 @10:39AM (#7077524)
      In fact, file-at-a-time encryption shouldn't be in the kernel, it is implementable in user code if you have the right hooks.

      While it is certainly possible to easily implement file encryption at the user/application layer, I disagree that it should be. Matt Blaze pointed out a number of reasons why in his CFS paper [crypto.com] back in 1993.

      ..if you do want disk-at-a-time encryption, StegFS strikes me as a better choice

      StegFS is a neat concept; the only drawback there is the huge performance hit -- besides, the goal of stegFS isn't necessarily to support encryption; it is meant to support plausible deniability of file ownership, and those two goals are very different.

      • While it is certainly possible to easily implement file encryption at the user/application layer, I disagree that it should be. Matt Blaze pointed out a number of reasons why in his CFS paper back in 1993.

        You are confusing implementation at the application layer with implementation in user mode. The crypto-code need not run in kernel mode in order to give users the same behavior and security as a kernel-based implementation; the kernel just needs to provide the right hooks.

        besides, the goal of stegFS
        • StegFS uses encryption to support deniability; the encryption is a tool, not an end in itself, and is certainly not the option (performance wise) if all you want is data confidentiality.

          As to your first point, I'm not sure what the distinction is...I'm saying that the behavior is too complex and not transparent enough if provided at the application level.

          An application can use its own code (in userland) to encrypt files. Fine. Or, an application can use kernel code (via whatever syscalls/hooks are provi

          • StegFS uses encryption to support deniability; the encryption is a tool, not an end in itself, and is certainly not the option (performance wise) if all you want is data confidentiality.

            Deniability itself greatly increases security, even if there is nobody with a rubber hose standing over you. And it is no accident that deniability requires strong cryptography: deniability is a stronger property, not merely a different property, than encryption.

            I'm saying that the behavior is too complex and not transp
    • What product for current versions of Windows are you referring to that offers disk at a time encryption. Note that that means being able to operate from an encrypted boot drive, not just being able to take a big file, call it a volume, and have it be encrypted.
      • What product for current versions of Windows are you referring to that offers disk at a time encryption.

        Do a search on Google; there is plenty of software around.

        Note that that means being able to operate from an encrypted boot drive, not just being able to take a big file, call it a volume, and have it be encrypted.

        I fail to see the difference. You can move most of the OS to an encrypted drive with Windows just like you would with Linux or BSD.

        Of course, there are also hardware-encrypted drives wh
        • Do a search on Google; there is plenty of software around.

          If it requires software, it isn't whole disk encryption that encrypts the whole drive and allows booting from it, unless there's a boot stub that can load the OS. Point me to one, or retract that "do a search" crack. I doubt you'll find one (other than in hardware, as you've mentioned.)

    • My main beef with StegFS, as I mention in my paper, is that it may put the user in a position from which innocence cannot be proven.

  • master key strorage? (Score:3, Informative)

    by graf0z ( 464763 ) on Sunday September 28, 2003 @10:16AM (#7077338)
    As far as i understood, GBDE uses - like many other crypto systems - different keys on different levels. There are "master keys" for protecting "sector keys". The master keys are only used for key-encryption, so they should be usable in slow crypting devices like cryptocards or usb cryptodongles. Since the master key never leaves such a token (master key operations are performed on an embedded chip), even a trojan with root privileges could only read data while the token is attached (in a way, they are "--x------"). Some of these cryptotokens even have an own input device (PIN-keypad) such that the passphrase for unlocking the keys cannot be sniffed.

    Is it possible to do that (instead of just keeping parts of the key on an usb storage device) with freebsd/GBDE?

    I think some ibm thinkpad T30 come with TCPA chip which could (at least theoretically) work as such a token, too.

    /graf0z.

    • If a malicious program had access to a token that performed decryptions using the master key, it could have the token decrypt all the sector keys and then peruse the disk at its leisure without further access to the token.
  • Seems to me that archives kept for decades should not be encrypted. Unless you keep the key right there with it, you're likely to loose it. Also, if there is degradation of the data you're likely to loose most of it even if you can find the key. Use physical access controls instead.

  • Poul-Henning replies... (Score:5, Informative)

    by phkamp ( 524380 ) on Sunday September 28, 2003 @11:20AM (#7077812) Homepage
    Lets see: NIH, OpenBSD, compatibility and all that.

    The paper explains this at length (but I guess that the respondent didn't actually read the paper). The primary focus in GBDE was usability and deployability. Most of the prior art in this space cannot even change the pass-phrase without reencrypting the entire disk (which can easily take an entire day).

    I wanted to do better than that, and I think I did. By a wide margin.

    RSA vs. SHA.

    Correct, that is a typo, it is SHA2 which is used.

    AES, zero IV etc.

    An important part of GBDE is that there is no two-way leverage on any crypto component. This is realized by the use of single-use random bit sector keys. With no two-way leverage and single-use keys, the IV is no longer important.

    The comment about the "plausible denial" setup being useless because an intelligent adversary would always take a mirror copy first: That does not affect the plausible denial aspect.

    I'll be more than happy to discuss any aspect of GBDE, and would very much like to hear peoples experience and ideas. But I would prefer email (if need be by setting up a mailing list)

    • Hi Poul,

      The comment about the "plausible denial" setup being useless because an intelligent adversary would always take a mirror copy first: That does not affect the plausible denial aspect.

      I assume you're referring to my comment - which wasn't that plausible deniability was not possible because of mirror copies, my exact comment was:

      From the paper: "A truly paranoid setup would leave the computer con-figured to boot the Windows system by default, and locate the GBDE data in such a way that it woul

      • Re:Poul-Henning replies... (Score:4, Informative)

        by phkamp ( 524380 ) on Sunday September 28, 2003 @01:35PM (#7078813) Homepage
        You're still missing the point :-)

        The setup I describe is how a "plausible denial" scheme could be set up. The bit about making a windows boot run over the GBDE data is just normal paranoia, it is not in any way related to or material to the plausible denial argument.

        I don't personally give much for "Plausible denial", finding a cover story for even a few megabytes of uncompressible bits will be very hard if not impossible with a skilled adversary.

        Therefore I focused in GBDE on giving the user leverage to a defensible non-disclosure stance. For instance by wiping out the master sectors if given enough seconds of warning. And in particular I wanted to make sure the user were never put in an indefensible position of compliance like for instance StegFS can do.

        For me it is important that people realize that GBDE is not a solution, it is a tool to implement solutions. With crypto there is no "one size fits all", only hard work and careful planning.

        • ok, well we both kind of agree that the idea of booting windows to destroy the volume header doesn't add any/much security against a serious adversary, which was the point I was trying to make....

    • What I have never understood about encrypted file systems is how they are supposed to be effective. Here's the problem as I see it:

      An encrypted file system needs keys for decryption. If keys are stored in a keystore on disk (most common), your data is at risk to anyone who can crack the keystore. This is made easier by the integration of many OSes to use your login password as the keystore password. Given the number of vulnerabilities that /etc/passwd files have, this doesn't seem like a good idea.

      To move

      • I guess what I'm trying to say, is that CryptoFSes only seem to help in the situation where someone steals your machine in a powered off state and fails to obtain your crypto keys. Unfortunately, many thefts occur while people look away for a moment, thus making such security useless.

        Any thoughts?

        Yes, some thoughts. You are right, this does NOT protect against stealing a "hot" disk, this only protects "cold" disks. The .pdf's from Poul-Henning also states this. So one would have to find another way to

        • You are right, this does NOT protect against stealing a "hot" disk, this only protects "cold" disks

          The problem is that the time it takes to boot precludes most users from shutting their machines off when not in use. The one exception to that is Mac iBooks. They are amazingly fast at sleeping and waking up. If the computer locked itself during a sleep, this would take care of the problem for iBooks. However, this still leaves issues with other portables.

          In X-Windows, the best thing I can think of is to fo

          • The problem is that the time it takes to boot precludes most users from shutting their machines off when not in use. The one exception to that is Mac iBooks. They are amazingly fast at sleeping and waking up. If the computer locked itself during a sleep, this would take care of the problem for iBooks. However, this still leaves issues with other portables. In X-Windows, the best thing I can think of is to follow the steps of Unix terminals and lock the computer after X minutes of non-use. You may be able

Slashdot Top Deals

"Trust me. I know what I'm doing." -- Sledge Hammer

Close