68264Re: Encryption: Vim should use authenticated encryption mode
- Feb 15, 2013On 2013-02-15 16:34, MacDonald, Stuart wrote:
> From: UlrikI think this is your misconception. It can't strictly be true, because
>> 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
> 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
> 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.
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 ownerTaken together, I think this is ridiculous. It is bad usability to give
>> 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.
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'm not a crypto professional, and so I have respect for the ample
> 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
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.
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 vim_dev+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic Next post in topic >>