Hi, Thanks for providing interesting package and accepting good part of my proposal.
For the record... I agree that if you chose good password, your eCrypted folder is safe. But how often do we have such good one :) Encryption key has 128 bit strength since it is generated from /dev/urandom and there is no established script to go over them to check if one possible key is the one used for encryption. This makes it practically impossible to try to run cracking scripts by scanning all possible cases. (Besides there is no easy existing script to do it.) On the other hand typical simple login password with 8 characters has only about 18 bit strength according to wikipedia article and thieves can check password with the hash value in /etc/shadow contents easily using established scripts (crack, john). http://en.wikipedia.org/wiki/Password_strength Please note such password is good enough for normal protection for logging into account. (Usually with system with shadow password and some time delay for login, this gives enough protection since each process of password verification takes time and shadow can not be read. About order of 1000 hours if we try each 4 seconds.) I agree that independent password does not give you extra bits of security as password bits unless you pay extra attention to the choice. But independent password is only used for encryption and there is no easy verification process. So use of it surely improves situation. > > diff -Nru ecryptfs-utils-64-base/src/utils/ecryptfs-mount-private > > ecryptfs-utils-64/src/utils/ecryptfs-mount-private > I don't think the new command line option is necessary. Just check for > the existence of the ~/.ecryptfs/wrapped-independent file. Agreed. It is historical :-) > > read -p "$MESSAGE" -r LOGINPASS > I reworked this a bit. Yes, it is nicer now. As for if echo "$LOGINPASS" |tr -d "\n"| ecryptfs-insert-wrapped-passphrase-into-keyring "$WRAPPED_PASSPHRASE_FILE" - ; then Then you can do with fancy "stty -echo". This is prelude to use zenity. Then we can have desktop file without terminal :-) (I have uncleaned version here ) > The 3 PW_ATTEMPTS is actually useful, ... Agreed. It is historical junk I had. > > diff -Nru ecryptfs-utils-64-base/src/utils/ecryptfs-setup-private > > ecryptfs-utils-64/src/utils/ecryptfs-setup-private > > I appreciate that you're adding support for single character short > options, but that really doesn't belong in this patch. A second patch > to do this would be much preferred, to keep the changes self-contained > and incremental. I'm dropping that change for now. I'll handle that in > a separate commit. Understood and thanks. > I'm going to handle the MESSAGE bits a little differently. Sure. > > + if [ "$LOGINPASS2" = "$LOGINPASS2" ]; then > > This will always be true. I fixed it. Call me stupid. > This "recommended" bit also doesn't belong in this patch. I'm dropping this > too. OK. > We only print passphrases to screen if they're randomly generated. If > the user has chosen their passphrase, and enters it twice, identically, > we're going to make the relatively safe assumption that they know their > passphrase. I was debating with myself ... OK. > Okay, I've tested this a bit, and committed it to upstream git. Thanks. > See the git commits: > * > http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=43da1692581c5c575550aab0ca54e9d85fe0a8b0 > * > http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=43da1692581c5c575550aab0ca54e9d85fe0a8b0 Hmmm... why two lines? Contents looks good to me though. > Also, I released version 65: > * https://launchpad.net/ecryptfs/trunk/65 Great! Osamu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
