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

68305Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • Mosh
    Feb 16, 2013
      On Sun, Feb 17, 2013 at 6:55 AM, Ulrik <ulrik.sverdrup@...> wrote:
      > On 2013-02-16 18:16, Bram Moolenaar wrote:
      >>
      >> Ulrik Sverdrup wrote:
      >>
      >>>>> The blowfish encryption mode is vulnerable (not to revelation of the
      >>>>> plaintext), but the encryption is not checked for integrity or
      >>>>> 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 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.
      >>>>>
      >>>>> The solution is an authenticated encryption mode. The common way to do
      >>>>> it is 'Encrypt-then-MAC' where a message authentication code is formed
      >>>>> from the ciphertext and the key. This code when matching will prove that
      >>>>> the document is unchanged and was produced by someone with access to the
      >>>>> key. This code will detect the previous attack case, and additionally it
      >>>>> allows vim to detect that the wrong password was entered. Security
      >>>>> practise says that Vim must fail with an error if the MAC does not match.
      >>>>
      >>>> I think that a verification key will actually make it easier to crack
      >>>> the password. Currently, when an attacker tries all kinds of passwords,
      >>>> he also needs a way to verify the decrypted text is actually readable.
      >>>> That is not so easy to do. With a verification key the verify part
      >>>> becomes really easy and fast.
      >>>>
      >>>> It is extremely difficult to change the file in a way that after
      >>>> decryption it is readable text. Probably just as difficult as cracking
      >>>> the password. When knowing that a file is only plain text, checking for
      >>>> invalid Unicode characters is probably sufficient to notice that the
      >>>> decryption failed.
      >>>>
      >>>
      >>> Using Vim 7.3 patches 1-547, this is not true, and it is trivially
      >>> testable (otherwise I would not have claimed it).
      >>>
      >>> Using :set cm=blowfish :X goodenough
      >>> I produced file A that ends with "I owe you 200 USD"
      >>>
      >>> using hex editor I flipped 1 single bit to produce file B, that ends
      >>> with "I owe you 300 USD". You can diff the two binary files by using:
      >>>
      >>> diff <(xxd A) <(xxd B)
      >>>
      >>> a one-bit difference in the ciphertext leads to a one-bit difference in
      >>> the plain text, and we have a false document and undedetected corruption.
      >>>
      >>> To reproduce, here are files A and B:
      >>>
      >>> xxd -r >A <<EOF
      >>> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780 VimCrypt~02!F8..
      >>> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7 3*...... ..y..l.
      >>> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba .C....j.......$.
      >>> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad ......l..C....j.
      >>> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7 ......$.......l.
      >>> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f .C....j.........
      >>> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c #"....Y.G...Zb..
      >>> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1 ...$....#"....Y.
      >>> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f G...Zb.....$....
      >>> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56 #"....x.[..L..mV
      >>> 00000a0: 32e5 962e b15c 000a f6 2....\...
      >>> EOF
      >>>
      >>> xxd -r >B <<EOF
      >>> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780 VimCrypt~02!F8..
      >>> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7 3*...... ..y..l.
      >>> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba .C....j.......$.
      >>> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad ......l..C....j.
      >>> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7 ......$.......l.
      >>> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f .C....j.........
      >>> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c #"....Y.G...Zb..
      >>> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1 ...$....#"....Y.
      >>> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f G...Zb.....$....
      >>> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56 #"....x.[..L..mV
      >>> 00000a0: 33e5 962e b15c 000a f6 3....\...
      >>> EOF
      >>>
      >>>
      >>> Note: I didn't search or brute force this, I only counted the right byte
      >>> offset in the file and flipped a bit. I really hope I am somehow
      >>> mistaken, but I don't think I am.
      >>>
      >>> Regarding quickening brute force by using a MAC, this is a false, the
      >>> MAC can have equivalent security factor to the block cipher, it should
      >>> really not be a concern.
      >>
      >> You could only make this change because you have seen the readable text.
      >> Without that you had no clue what bits to change to get any desired
      >> effect. Exactly the same thing could have been done on the unencrypted
      >> text, but then obviously it is possible to change what you desire.
      >> However, the encryption does not have to goal of making these changes
      >> impossible or even difficult.
      >>
      >> The whole point of the encryption is to make the text unreadable. It is
      >> not a signature of any kind. Signing files, encrypted or not, is a
      >> totally different thing and there are plenty of tools for that.
      >>
      >
      > The type of the attack is that if you XOR a value with the ciphertext,
      > the same XOR difference shows in the decrypted text. Knowing a small
      > part of the plaintext is not a big requirement on an attack as simple as
      > this one.
      >
      > I understand that Vim only wants to provide confidentiality, not
      > integrity, but taken together with the usability issue of not giving
      > notice of a wrong password, I don't understand the choice. I don't enjoy
      > the possibility given that I might absent-mindedly type :w when getting
      > the garbage output after a mistyped password, destroying my data.

      Yes, this is a problem.

      > (The only reason I bring these up together is that a MAC would allow Vim
      > to easily detect if the password is correct.)

      It is easy to save the checksum (1 or 2 byte of the final iv into the
      header), so
      we could check for errors after decrypting, but this will bump up the
      version number
      of vimcrypt to ~03.

      >
      > The frontiers for encryption have changed during the internet era and
      > since Blowfish was published (1994). Current best practices give the
      > users much more safety. View it as a development history where
      > accumulated patches have created a more reliable product, if you want.
      > Vim entering the "strong encryption" field, with Vim 7.3, in this way is
      > unfortunate, because it looks more like the solutions date from the 1990's.
      >
      > Best Regards,
      > -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.
      >
      >

      --
      --
      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