<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Times New Roman"><br>
Hi,<br>
Sorry about the delayed response. To be frank, I haven't think
over these stuff <br>
seriously. I didn't expect too much about the module at first. Now
I know I was <br>
wrong. I shouldn't get through it rashly－</font><font face="Times
New Roman"><font face="Times New Roman"> people are watching on
me!<br>
</font>And I believe I can make it with the help and advice I got
from all of you. </font><br>
<font face="Times New Roman">Thank you!</font><br>
<span style="color: rgb(67, 67, 67); font-family: Arial, sans-serif;
font-size: 14px; font-style: normal; font-variant: normal;
font-weight: bold; letter-spacing: normal; line-height: 24px;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline
!important; float: none;"></span><br>
<blockquote cite="mid:52206.1392910334@turing-police.cc.vt.edu"
type="cite">
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="https://epic.org/crypto/scarfo.html">https://epic.org/crypto/scarfo.html</a>
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. :)
</pre>
</blockquote>
Regards <br>
Freeman Zhang<br>
</body>
</html>