On 11/08/2014 06:45 AM, listreader wrote:
The brtfs looks fine, or at least I can browse what's in there. The xfs partition, though, appears broken. I had LUKS encrypted it during the install/format process but when I try to mount I get the familiar bad old message about:
I am massively in favour of encryption, no matter what the FBI says, no matter what the NSA says about it being the death of the 'berry. http://www.zdnet.com/former-nsas-chief-lawyer-blackberrys-encryption-efforts... But you'll note that both of these have to do with mobile devices. You'll also note, I hope, that many of the stolen USB "breaches" were unencrypted data on a _mobile_ data store. I'm also massively in favour of encrypted data channels! But I don't encrypt data on static machines. (usually) An encrypted FS or data store that is available in the clear while the system is booted anyway makes no sense to me. It only makes sense if the machine itself is physically insecure, that the drive could be stolen. And not really even then; if the machine is physically insecure the whole thing could be stolen, and booted, or the data extracted while the machine was running, or, given physical access, a keystroke recorder could be plugged in. Per user encryption that is only made available in the clear by the user, possibly, though I hope not, when the user logs in, begins to make sense on a static machine that is protected from some classes of physical hacking. One might reason that the "My Accounts" (or "My Nude Pictures") is encrypted and only unencrypted while the appropriate application is run, and re-encrypted at the end of that run. Never the less, if the (static) machine is not physically protected a keystroke recorder can be used to get the key prior to stealing the encrypted data. If the (static) machine is physically protected then I don't see the justification for encrypted file system that is mounted & unencrypted, at boot time by the kernel and kept unencrypted while the system is running. It might make some marginal sense if the machine is off most of the time, but I'd be hard pressed to justify that myself. Then there's the issue of backups. Are they done of the encrypted FS or are they done of the running, unencrypted FS? Are the backups, which are not on portable media, encrypted and/or physically protected? Then we get into the thorny matter of key management. If the kernel is to automatically unencrypt & mount the FS at boot time then the kernel need to know the key or have the key to the key management system (which may be an encrypted file... And so on regressing indefinitely) I'm sure people are going to disagree with what I've said. I *DO* want to hear other reasoned views. But before you do, read what I've written carefully. I've tried to make clear the difference between mobile devices and mobile data on the one hand, and static machine such as servers (in farms, at service providers) on the other, and to make clear that the risks associated with allowing unlimited physical access to static machines cannot be fully mitigated by encrypting file systems or even individual files. Derived from the latter, if you have physical protection then the value of encryption is ruined if the machine is running with the file system mounted clearly accessible. However it is the MOBILE which concerns me most. That includes backups from the static machines. If we are talking about mobile data in any form, be it backup takes, on cell phones/tablets, on laptops & chromebooks, or stored in the cloud and flowing backwards and forwards, then there is a good justification for encryption. Encryption is not a magic ointment that one applies to cure ills and protect from hackers. Having that attitude will lead you to disaster in one form or another. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org