Hi, Sorry about the delayed response. To be frank, I haven't think over these stuff seriously. I didn't expect too much about the module at first. Now I know I was wrong. I shouldn't get through it rashly-people are watching on me! And I believe I can make it with the help and advice I got from all of you. Thank you!
> The first question is - what are you trying to protect against? The > answer to that will influence your design. > > As Bruce Schneier said in the intro to Applied Cryptography: > > There are two kinds of cryptography in this world: cryptography that will stop > your kid sister from reading your files, and cryptography that will stop major > governments from reading your files. This book is about the latter. > > It's one thing to write a silly kernel module that will rot13 your > files. It's totally another to design a complete system that works. > > Do you need to worry about a directory being open for access to encrypted > files, and another rogue process on the system simply going and reading > the files and the crypto doesn't matter? (This is an issue for cryptLUKS, > for instance - it defends against somebody stealing a powered-off laptop, > but not against processes that get access to a running system. You may wish > to think for a bit about what security is provided by a system that is > suspended, rather than powered off - particularly in the case of > cold-boot attacks....) > > Do you need to worry about somebody replacing the binary that prompts > the user for the passphrase before loading it into the kernel, with a > version that saves the passphrase for later, after the device has been > "recovered" via theft or similar? (And yes, this *has* been used before, > see 'FBI v Scarfo', where they installed a keylogger to snag a PGP passphrase: > > https://epic.org/crypto/scarfo.html > > Do you need to worry about other more generic keystroke loggers? > > Do you need to worry about the fact that most user passphrases won't > have enough entropy to be used directly as crypto keys? If you merely > use the passphrase for salting a randomized key (such as the way gpg, > ssh, and cryptLUKS use your passphrase), how do you address the problem > of insufficient random entropy at key generation time? > > That's just the obvious stuff you will need to worry about. :) > Regards Freeman Zhang
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
