Date: Sun, 29 Jan 2006 12:10:34 +0100 (CET) From: Christian Baer <christian.baer@informatik.uni-dortmund.de> To: freebsd-security@freebsd.org Subject: Re: Should I use gbde or geli? Message-ID: <dri7ra$1ouq$1@nermal.rz1.convenimus.net> References: <drgdg9$1klu$9@nermal.rz1.convenimus.net> <20060129022943.GJ2341@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Jan 2006 13:29:43 +1100 Peter Jeremy wrote: > Security is not an absolute - it's a cost/benefit analysis. I know that and it's something I "feel" every day. I have a rather long pass-phrase for my gpg-key, which is a real pain to type sometimes. This pain is the downside (cost) of security. And is something I have taken into consideration. We may have to work on workflows for a while when we try to perfect the security while still leaving the actual work as uninfluence as possible, but that is a completely different problem. > Your friend needs to consider the value of his data, who is likely to > want to steal it and what resources they have available. I suggest > you have a read of some of (eg) Bruce Schneier's recent books. I am reading up on the basics of this subject. However, the theory doesn't really cover too much of the practical sides like the real differences between approaches or even gbde and geli. > With virtually any modern, properly implemented crypto solution, the > weaknesses in the system are going to be human not technical. Your > friend is far more likely to have his data stolen via a disgruntled > employee, a secretary being conned into giving out the password, > spyware copying the unencrypted data or someone arriving with a gun. > Have a close look at what has access to the data when it is > unencrypted - it's far easier to steal this way than having to break > the encryption. Human failure can never be ruled out, if you can call being forced to do something at gunpoint a "failure". But we went through a lot of scenarios and some are just more unlikely than others. Taking something by force (the gun-idea) is a very different crime than stealing something during a break-in. Getting away with a break-in seems far more likely than getting away with a crime that includes violence. So to our consideration, it is far more likely that someone actually tries to steal the information rather than take it by force. As silly as it may seem, we believe that there are certain lines that the competitors just won't cross. We are talking about Germany, not the United States. With all that said, we are still looking for a maximum of security for the information. Workflows are being optimized - some have already been changed to be more secure - but so far we also want to rule out a technical flaw, or rather a weakness in the chain cause by such a flaw. The actual keys and pass-phrases will only be known to the two bosses of the firm and to myself (which btw. wasn't my idea). Forcing the secretary hand out the pass-phrase is therefore not really helpful (because she doesn't have it), but I guess you could still threaten the families of my friend or his partner. I know that a trusted employee can always turn on you. But for the moment let's assume that they will not do so und thus will not willingly hand over or sell sensitive information. One of the aces we may have is the fact that noone (including the employees) will know that the information is encrypted. This way a theft could look more promising and if it succeeds the thief will find out that what he stole is worthless (apart from the hardware itself). > Realistically, neither are going to fall to a brute force attack in the > near future. Both use AES so a break in AES is likely to equally affect > both (though a partial break would have a bigger impact on 128-bit AES). > You probably need to spend more time thinking about the passphrase that > you use to secure the master key - unless that has at least 128 (or 256) > bits of entropy, it will be quicker to break the master key. The pass-phrase consists of a string of characters with a length of about 1024 bytes. It hasn't actually been generated yet but the plans are to create a long string of entropy (something like 800 bytes) and then a part that can be memorized. This way the idea of "something you have" and "something you know" can be used. This seems a little oversized, because the anount of possible character-combinations is much larger than the amount of the hash's combinations but in case for some reason the hash is broken and some of the pass-phrase's characters are known, there are plenty of permutations to try so brute force shouldn't even work in that case. We have been talking of AES all the time. How secure is blowfish? It's open source but not too well analysed so far. Can you say something about that. I have a problem trusting something that the NSA suggests, as there is always the possibility of a flaw in that. I know, some wild conspiricy, but worth a consideration at least. > You need to take into account the likelihood of the alarm system false > triggering or a burglar stealing the computer without setting off the > alarm. You might find it easier to protect the master keys with a > (volatile) passphrase and rely on adequate protection of the > passphrase. (You might also consider looking up "secret sharing" > "threshold system"). I'm not really sure where you're going with this volatile pass-phrase. Both gbde and geli (AFAIK) don't save the pass-phrase on the disc. So they are by definition volatile. If some burglar were to steal the computer it most likely would be cut off from power. This way the discs would be "cold" and the information safe. The bigger risk would be the burglar copying the information. Or am I missing the point here? >>After considering this, am I better off with gbde or geli? Have I missed >>anything in my little list? > How will backups be protected? I have only thought up a method, now a complete solution (which would include choosing the software). The idea is to use a software similar to truecrypt. The backups would be made in some sort of container and then copied to DVD-RAM. After that the backups would be locked away. Regards Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dri7ra$1ouq$1>