On Saturday, March 19, 2016 at 1:43:30 PM UTC-5, Demetri Obenour wrote: > Argon2 is implemented in libsodium and is the winner of the Password Hashing > Competition. It is designed as a KDF. > > > However, note that the rest of Vim's cryptmethod is also poorly implemented. > My suggestion is to use Argon2 as a KDF and either XSalsa20-Poly1305 or > XChaCha20-Poly1305 (with a strong, random nonce) for authenticated encryption. > > > libsodium provides high-level APIs for password hashing and authenticated > encryption and is my strong suggestion. > >
My thoughts on this are: It's best to use a library. With a library we're going to get any security updates from people who presumably know what they're doing and spend time learning about exploits so they can address them in their code. Also researchers are actually likely to test an external library, but not Vim's internal code. However it's useful to have *something* available on every system Vim supports, so I think something should be baked in, still. Also Vim needs to be able to read old files. I think adding a 'cryptkdf' option would be a decent idea. Include something built-in; either copied from a library with a license that allows it (probably best), or something simple like PDKDF2 (we already have a SHA256 we could use a a building block). But also include an option for a library implementation of a few algorithms. Argon2 is a good idea but it's still pretty new so if a flaw is found another method would probably be nice to have already available, so maybe the choices could be something like 'pdkdf2', 'lib-scrypt', and 'lib-argon2' for starters. The number of iterations is key for the security of these algorithms. I'm vaguely aware that scrypt and argon2 are also configurable in memory use, but I know a lot less about that. But regardless we'll want to allow configuring the KDF to scale with hardware without recompiling Vim. So a 'cryptkdfcount' or similar option should also be provided. I think a good way to do this would be to allow both numeric values, but also time values. For example, the user could do ":set cryptkdfcount=1s" and Vim would estimate how many iterations would take a full second on the current hardware and use that. 1-3 seconds is probably a reasonable default value as well. 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. As for blowfish: I'm not very concerned about the weaknesses in the algorithm *for the specific uses Vim is likely to use it for*, however having a better encryption algorithm available is much nicer. Nevertheless, I *am* a little concerned whether we know the algorithm is implemented properly. I'd like to see output from Vim's implementation matched up against output from a well-known library implementation. In theory with the same salt, same IV, and same key, I think they should be compatible. I should note here that I'm also a little uneasy with the current salt/IV generation. Basically it's just one system time (in microseconds) and a hash (I doubt the rand() adds anything useful). That could be a lot better, using /dev/urandom for example where supported, or the equivalent. Or maybe hash system time (still in microseconds) with a previous hash periodically, say while waiting for user input or something; I'm not familiar with best practices when a good system-provided random source is missing. I say I'm "uneasy" because I doubt there's any good exploit for this in Vim's use scenarios, but it's documented widely that a good unpredictable IV is required for CBC mode encryption, so I don't get any warm fuzzies from the "random" code here. Bram, are you already working on any of this? I have been thinking about starting an implementation of some of the above but that's a lot of work I don't want going to waste if you have other ideas. Maybe hashing out a top-level interface and goals, then making a fork for more distributed development, would be a decent idea? I don't think any halfway implementations will be useful, especially since we'll probably need to grow a blowfish3 or other cryptmethod to use the new KDF (preferably in a forwards-compatible way to handle other new KDFs that may come along in the future). -- -- 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.
