Loading ...
Sorry, an error occurred while loading the content.

68264Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • Ulrik
    Feb 15, 2013
    • 0 Attachment
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Show all 22 messages in this topic