On 2013-02-15 16:34, MacDonald, Stuart wrote: > From: Ulrik >> Sent: February-14-13 1:00 PM >> The blowfish encryption mode is vulnerable (not to revelation of the >> plaintext), but the encryption is not checked for integrity or > > I suspect the real problem is a weakness in Vim's blowfish > implementation. > > But yes, I can reproduce this with gvim73_46.exe on > Win7 64-bit Enterprise. > >> authenticity. This means that someone might corrupt the encrypted file >> (hexedit or similar), and vim will decrypt it without notice of error or >> warning. > > This isn't supposed to happen. A strong encryption algorithm will > render completely different crypt text for even a single bit change in > the plaintext, and, a single bit change in the crypt text is supposed > to decrypt to corrupt plaintext. >
I think this is your misconception. It can't strictly be true, because the uncorrupted prefix of the file will always decrypt ok. To truly render the *whole* decryption corrupt when the ciphertext is altered, that would require a multi-pass encryption algorithm. I modern crypto the error propagation and error detection discussions have totally vanished and authenticated encryption has taken its place; the new paradigm requires verified authenticity and integrity or discarding the message! I agree that Vim might have implementation issues. I have looked into the code and it says Blowfish with OFB mode however I cannot get the code or the behavior to line up with any block cipher mode I know of! >> This attack allows someone to modfiy encrypted files so that the owner >> doesn't notice. With sufficient tries or skill it might be possible to >> change a file's values in a predictable way at a certain offset. > > Agreed that someone can modify a VimCrypt file and have the > modification propagate into the plain text. However, for this to be a > useful attack I think that the plaintext already needs to be known > which is unlikely, and if it is known, given the plaintext and the > crypttext, it won't take to long to find the key, and then you can > make all the changes you want. > > I'm more concerned that this indicates there is a bug in Vim's > blowfish implementation and that will allow keys to be recovered more > easily. *That's* a big problem. > >> The solution is an authenticated encryption mode. The common way to do > > Perhaps, but only if this effect turns out to be endemic in blowfish > and not a result of the implementation. I feel strongly that we need > to examine the implementation first. > >> key. This code will detect the previous attack case, and additionally it >> allows vim to detect that the wrong password was entered. Security > > When the wrong password is entered the file decrypts to garbage, as it > should. There's no need to through an error there. If the file is > corrupted (as per your test or disk failure or cosmic ray) then it is > supposed to decrypt to garbage. Taken together, I think this is ridiculous. It is bad usability to give the user garbage output, as mistyped keys will happen to anyone. Instead you give them the opportunity to absent-mindedly save the garbage (destroying their data), or confusing them. > > I don't see a need for an authentication scheme, but then, I'm not a > security programmer by profession so I'm a novice and could be > incorrect. > > ...Stu > I'm not a crypto professional, and so I have respect for the ample documentation you can find about current best practice, and if Vim wants to go forward with a better encryption scheme, we must absolutely respect these practices. -ulrik -- -- 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/groups/opt_out.
