From mboxrd@z Thu Jan 1 00:00:00 1970 From: freeman.zhang1992@gmail.com (Freeman Zhang) Date: Mon, 24 Feb 2014 09:52:13 +0800 Subject: [Help] How to Replace File Operations in File System? In-Reply-To: <52206.1392910334@turing-police.cc.vt.edu> References: <52FC29B3.10201@gmail.com> <52FC69C7.7010705@gmail.com> <52FCC870.3010303@gmail.com> <5302E2DC.1040308@gmail.com> <53055B1B.5000500@gmail.com> <5305C387.3000506@gmail.com> <5305CF57.7090905@gmail.com> <52206.1392910334@turing-police.cc.vt.edu> Message-ID: <530AA5CD.4060601@gmail.com> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140224/a55c2815/attachment-0001.html