1. It is working correctly as designed, see the specs on how encryption works:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
and note the details on single bit corruption and its effect on blocks,
and error propagation across blocks.
2.
>> 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.
This argument is not true for blowfish or any good encryption algorithm.
---
On Fri, Feb 15, 2013 at 9:04 PM, MacDonald, Stuart
<[email protected]> 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.
>
>> 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.
>
> 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
>
> --
> --
> 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.
>
>
--
--
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.
