On Thu, 11 Jul 2013 08:49:13 +0800, you said: Note: You're usually better off discussing things on-list. That way, everybody gets to learn something, and you have a better chance of soembody else providing information besides just me. Redirecting to list. > Thank you for your quick response but here i wanna implementation of > transparent encryption in the kernel,as user can not realized what he send > data had encrypt in kernel, and when they want get ,they will get decrypt > data. OK.. This is where it gets very tricky very fast. :) The problem is that it's *very* hard to do truly transparent but yet secure encryption. Let's work through one example in detail - cryptLUKS. cryptLUKS is designed to protect against data theft or modification of a system that's turned off (for instance, a laptop sitting in a laptop bag in a hotel or airport). To do this, the user has to enter a passphrase at disk mount time, providing the encryption key. Somebody steals the laptop, they don't have the key, and they can't access the contents of the disk. Now what happens if we configure it so tha there is no passphrase, and it automatically supplies the proper encryption key by itself? Then the bad guy who stole the laptop can just boot it, watch the system supply the encryption key, unlocking the disk, and now he can access it - you now have exactly zero actual security. (This is a trivial example of the fact that crypto systems are almost never broken by actually attacking the crypto algorithm - in almost every single case, the actual break is in how the software/hardware does key management) Note that cryptLUKS *does* have a few issues - for instance, it doesn't by itself protect against an "evil maid" attack where somebody modifies the initramfs to capture your passphrase, and there's certain classes of cold boot attacks that can also get the encryption key. So although it provides sufficient protection against "guy steals laptop to support his drug habit", it doesn't fully cover all the bases. If you have *serious* reason to think that the FBI, a rival company, a pissed-off hacker ex-lover, or somebody would want your data enough to backdoor your initramfs, then you're going to need stuff like secure boot to fully close all the holes. That's why in my first mail I asked: 1) What data you're trying to protect (how much, general type, etc) 2) Who you're trying to protect it from 3) How much non-transparency are your users willing to put up with In other words, you really need to understand the threat model, and how various cryptographic techniques address aspects of the threat. And also - it's almost always a mistake to design your own crypto system, even if your last name is Schneier or Rivest. *Everybody* can design a system they can't break themselves. Doing one that nobody else can break either is a whole different story. (Even Bruce Schneier didn't trust his own Twofish or Blowfish algorithms until they'd gotten some serious review by other top cryptography experts).
Attachment:
pgpkcVI0OW1p6.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
