Saturday, February 7, 2015

Re:Re: Re: Re: Re: why not vim7.4 have blowfish2

Tora wrote:

> I suggest some features for vim improvement.
>
> In my humble opinion, the next thing to do is to enhance vim's
> encryption. It could implement more encrypt methods like CAST5,
> TWOFISH, AES256 etc. One studpid feature is that vim prepends a 'magic
> string' --- 'VimCrypt~..' on the encrypted file, which is COMPLETELY
> no use except for telling crackers that it is encrypted with vim and
> its encrypt method. Vim encrypted file should get rid of any thing
> that would reveal it is vim encrypted and its encrypt method. Then,
> how to read it back? Vim will never know if it is vim encrypted and
> the encrypt method. It is easy. First, vim will read in an encrypted
> file and display a mess with binary mode. Sceond, the user inputs
> command like ':Z blowfish' or ':Z cast5' in vim, which tells vim to
> decrypt the mess with blowfish or cast5. If that file is not vim
> encrypted but an real executable or user has inputted a wrong key, vim
> still uses that key to decrypt and another mess would display. This
> will greatly improve the robustness of vim encrypted file. By
> enhancing its encryption in this way, vim could greatly spread over
> the world and other editors become truly nothing. Vim becomes a weapon
> with deity.

When we discovered the currently supported encryption is rather weak, I
asked about implementing a modern encryption method. Unfortunately,
nobody with sufficient skills stepped forward. Someone started but the
work stalled, and I had to finish the current encryption myself. Thus
implementing another crypt method depends on someone knowledgeable to do
the work. It requires an expert, because it's easy to make a mistake.

Although leaving out the header would make it more difficult for an
attacker to know how to decrypt, it also makes it very user unfriendly.
Vim can't prompt for a password, because it has no idea what kind of
file it is. If you would really want this, I think we would need a
special option for that. The user would then have to enter both the
password and the crypt method.

Note that I have not included a checksum in the header, because it would
make it easier for an attacker to try guessing the password. It's still
possible, but slower (need to analyse the text after decryption to see
if it looks like words).

> By the way, the improvement of vim should never stop. If it stops,
> then vim will perish --- definitely. But the degree of improvement
> could vary. This is one stripe of balance, which we have been seeking
> in the universe.

Yes, but we also need to avoid it becoming too complex.

--
hundred-and-one symptoms of being an internet addict:
194. Your business cards contain your e-mail and home page address.

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments: