encrypt data

[Valdis.Kletnieks at vt.edu]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130711/568f24e4/attachment.bin