On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar <[email protected]> wrote: > > > Speaking of defaults: I think Vim should default to the strongest > > method available. I additionally think Vim should warn on saving with > > a known broken format such as the original blowfish implementation, or > > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even > > compile without the broken algorithms altogether unless the user > > specifically passes --include-bad-crypto to the configure script or > > something. > > This has the danger of writing a file on one system, go on holiday and > find out you can't open it on your laptop (that actually happened to me). >
That makes some sense, however it only applies to people who edit the same file on multiple systems, AND they don't have the same version of Vim on each of those systems. If you don't need that capability, having the old broken systems still in the code makes it too easy to make a mistake that could compromise your security. DROWN recently showed some of the problems with keeping older known-broken crypto code enabled by default. I think it makes sense to keep the code there for people who deliberately choose to use it. But getting rid of it by default can potentially remove an attack vector. At the very least, we should warn when saving in an insecure format. > I think there should be some number of months between making a new > method available and making it the default. > OK, that's fair. > The original blowfish encryption is not broken, it's just weaker than it > should be. It's still a lot stronger than zip. Is it? This page makes it sound like "blowfish" was pretty much completely broken if you knew any of the plaintext: https://dgl.cx/2014/10/vim-blowfish For example, if you had plugin that always writes a predictable header text to an encrypted file before the actual sensitive data, the attacker would know some plaintext. I'm certainly not comfortable using "blowfish", knowing it had exploitable flaws fixed in blowfish2. I thought "blowfish" was just around to let people read their old data (and hopefully convert to blowfish2). And while I can probably *personally* use a strong-enough passphrase to let the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it to anyone else, since I know most people choose passwords that can fall way too fast with modern tools and techniques. I'd consider "blowfish2" to be broken for *general use* as well since you need a REALLY good password for it to provide any long-term security guarantees. Once we increase the KDF iterations sufficiently I would warn when saving in blowfish2 as well, in favor of the new method(s) using a better KDF. -- -- 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.
