Google search for "working to weaken encryption standards" and connect the dots. I can't really debate with academics who can't code.
User can read vim help and then google blowfish to wikipedia, On Fri, Feb 19, 2016 at 9:34 PM, Ben Fritz <[email protected]> wrote: > 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. > -- -- 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.
