On Friday, February 19, 2016 at 9:19:18 AM UTC-6, Thiago de Arruda wrote: > > Since Vim is installed and Bob knows it uses SHA256 as KDF, he decides to > give it a shot at brute forcing with a popular password cracker with GPU > support. If Alice has a weak password(which is not so uncommon for > non-technical users), there's a good chance Bob will break the encryption. > > > I think the point @atoponce / @tarcieri are trying to make is that no > encryption is better than weak encryption, as it can give a false sense of > security to users. > > > I know that Vim is free and offers no warranty, and removing this feature may > not be an option. But a fair warning at the documentation for the -x option > wouldn't hurt: > > > > -x Use encryption when writing files. Will prompt for a crypt key. > Don't use it for highly-sensitive > > data as the encryption used contains some known vulnerabilities: > (link to this issue or some > > documentation that explains the problem) > >
OK, I'll concede the point about the weak KDF. That could be a lot slower to improve the situation for weaker passwords. It could be a really really nice patch to add a new cryptmethod, or maybe a new cryptkdf, option that supports something like scrypt. But, AFAIK Blowfish as an algorithm is not "broken", especially regarding the expected uses here. There are some attacks that are possible with 2^34 (several BILLION) known or chosen plaintexts, which will certainly not be the case when attacking one or two files encrypted by a Vim user at some point. And there are apparently problems with very large (gigabyte sized) plaintexts; again this would be very unlikely for a Vim user to have. Admittedly I'm a bit out of my area of expertise here, and I certainly would not feel qualified to actually write the crypto code, but throwing out a perfectly good algorithm for reasons that sound cargo-cultish rather than a reasoned thought process about the expected use cases seems less than ideal. That said, I think I'd like to see something like this in a perfect world: 1. A new cryptmethod, that does the encryption through a 3rd-party library. Bram is awesome, but I don't think he's a crypto expert. And with a 3rd-party library we'll get any security fixes for free, plus there will be plenty more people looking at the code to find issues. 2. Options for selecting/tuning the KDF. SHA256 is not a great one to use anymore, unless we use a heck of a lot more iterations. Something designed to be slow would be much better. 3. Vim should automatically select the strongest available cryptmethod at startup and a reasonably strong set of KDF options (maybe tuned to take 1 second on the current hardware, for example). 4. Possibly, an option to *automatically* upgrade the cryptmethod to the current setting, if editing a file using an older weaker cryptmethod (especially useful for original blowfish or even zip encryption). 5. I still don't understand why "at rest" data would need a MAC from a confidentiality standpoint, but since it could help you discover whether the data is corrupt, sure, we could add a MAC to the new cryptmethods. 6. Probably a warning when setting cryptmethod that is not the strongest available would be appropriate. But it should be kept for backwards compatibility, e.g. if you need access to the file on systems where you can't upgrade your Vim. Plus you may not always have the external library available. -- -- You received this message from the "vim_dev" 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_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
