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

Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • Mosh
    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
    Message 1 of 22 , Feb 16, 2013
    • 0 Attachment
      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
      <stuart.macdonald@...> 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 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.
    • Bram Moolenaar
      ... 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.
      Message 2 of 22 , Feb 16, 2013
      • 0 Attachment
        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.

        --
        We apologise again for the fault in the subtitles. Those responsible for
        sacking the people who have just been sacked have been sacked.
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        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.
      • Ulrik
        ... 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
        Message 3 of 22 , Feb 16, 2013
        • 0 Attachment
          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.

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

          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.
        • Mosh
          ... Yes, this is a problem. ... 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,
          Message 4 of 22 , Feb 16, 2013
          • 0 Attachment
            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.
          • Ben Fritz
            ... I still don t think preventing this kind of attack is within the scope of Vim s encryption. ... But I think THIS is an excellent argument for your proposed
            Message 5 of 22 , Feb 18, 2013
            • 0 Attachment
              On Saturday, February 16, 2013 7:25:54 PM UTC-6, Ulrik wrote:
              > On 2013-02-16 18:16, Bram Moolenaar wrote:
              >
              > > 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 still don't think preventing this kind of attack is within the scope of Vim's encryption.

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

              But I think THIS is an excellent argument for your proposed feature. If we can easily protect the user from accidentally corrupting their important file, then it is a very good idea. There is already checksum code within Vim for the undo file...I think it uses some sort of SHA algorithm. I don't think this should be too hard to implement.

              I think :w! should force a write even though the checksum is wrong just in case somebody is doing something kooky intentionally, but :w with a mismatched checksum should give an error.

              As somebody mentioned, the encryption already stores a version flag in the file, so this should be a backwards compatible change.

              Should a file which was read without the checksum, also be written without one? I normally wouldn't think so, but perhaps it would be best to prevent that older Vims can't read the file after editing it in a newer Vim.

              A recent patch also added a vimscript function to get the checksum, I wonder if that could be used to do this as a plugin. I think it would be better built-in however.

              --
              --
              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.
            • Mosh
              I am happy to report that our vim encryption implementation is NOT affected by any of the weaknesses in the encryption algorithms and implementations in news
              Message 6 of 22 , Sep 22, 2013
              • 0 Attachment
                I am happy to report that our vim encryption implementation is NOT affected
                by any of the weaknesses in the encryption algorithms and implementations in news recently, e.g.






                On Mon, Feb 18, 2013 at 10:05 PM, Ben Fritz <fritzophrenic@...> wrote:
                On Saturday, February 16, 2013 7:25:54 PM UTC-6, Ulrik wrote:
                > On 2013-02-16 18:16, Bram Moolenaar wrote:
                >
                > > 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 still don't think preventing this kind of attack is within the scope of Vim's encryption.

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

                But I think THIS is an excellent argument for your proposed feature. If we can easily protect the user from accidentally corrupting their important file, then it is a very good idea. There is already checksum code within Vim for the undo file...I think it uses some sort of SHA algorithm. I don't think this should be too hard to implement.

                I think :w! should force a write even though the checksum is wrong just in case somebody is doing something kooky intentionally, but :w with a mismatched checksum should give an error.

                As somebody mentioned, the encryption already stores a version flag in the file, so this should be a backwards compatible change.

                Should a file which was read without the checksum, also be written without one? I normally wouldn't think so, but perhaps it would be best to prevent that older Vims can't read the file after editing it in a newer Vim.

                A recent patch also added a vimscript function to get the checksum, I wonder if that could be used to do this as a plugin. I think it would be better built-in however.

                --
                --
                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.
              • Rhialto
                ... The code in Vim uses the words Output feedback mode and the 3 letters ofb in a few places around bf_crypt_encode(), thereby suggesting that it is
                Message 7 of 22 , Jan 11, 2014
                • 0 Attachment
                  On Sat 16 Feb 2013 at 20:21:48 +0530, Mosh wrote:
                  > 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.

                  The code in Vim uses the words "Output feedback mode" and the 3 letters
                  "ofb" in a few places around bf_crypt_encode(), thereby suggesting that
                  it is indeed using the Output FeedBack mode.

                  However that isn't actually true. The code isn't really clear but I
                  think it seems most like CFB: the plaintext is XORed with the output
                  from the block cypher and given back to the block cypher in the next
                  block. This became visible only when I drew a picture and compared it
                  with those on the wikipedia page.

                  It looks like that without the macro "BF_OFB_UPDATE" the code would
                  actually implement OFB.

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

                  Actually it can definitely be true. And that isn't due to a deficiency
                  in Blowfish or its implementation, but when OFB mode is used. And as
                  long as the code suggest that OFB indeed is used, this counts as a
                  vulnerability in itself.

                  As you can see at
                  http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_feedback_.28OFB.29
                  when decrypting in OFB mode, a corruption in one cyphertext block does
                  *not* propagate to any next block! In effect, the block cypher is merely
                  used to generate a stream of pseudo-random bits which are

                  Note I'm not a professional cryptographer, but I've made a few crypto
                  thingies in the past and got lambasted for the stupid mistakes I made in
                  them. This taught me that it is much more difficult to get it right
                  than to get it wrong, and about some of the mistakes that any
                  non-careful implementer oh so easily makes.

                  I would suggest updating the terminology in blowfish.c, and then have
                  another few people look at it to triple-check it.

                  Oh, and I too think that decrypting to garbage without an error message
                  is really the wrong thing to do.

                  -Olaf.
                  --
                  ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
                  \X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'
                • Rhialto
                  Oops, pressed send too soon. ... XORed with the plain text to generate the ciphertext. Which means that an attacker can trivially flip any bits in the file
                  Message 8 of 22 , Jan 11, 2014
                  • 0 Attachment
                    Oops, pressed "send" too soon.

                    On Sat 11 Jan 2014 at 18:26:28 +0100, Rhialto wrote:
                    > As you can see at
                    > http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_feedback_.28OFB.29
                    > when decrypting in OFB mode, a corruption in one cyphertext block does
                    > *not* propagate to any next block! In effect, the block cypher is merely
                    > used to generate a stream of pseudo-random bits which are

                    XORed with the plain text to generate the ciphertext.

                    Which means that an attacker can trivially flip any bits in the file
                    that (s)he wishes.

                    -Olaf.
                    --
                    ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
                    \X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'
                  • Bram Moolenaar
                    ... Right, it looks like the code is doing CFB instead of OFB. ... So, CFB is better than OFB? Then we are fine. ... It does make an attack more complicated.
                    Message 9 of 22 , Jan 11, 2014
                    • 0 Attachment
                      Olaf Seibert wrote:

                      > On Sat 16 Feb 2013 at 20:21:48 +0530, Mosh wrote:
                      > > 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.
                      >
                      > The code in Vim uses the words "Output feedback mode" and the 3 letters
                      > "ofb" in a few places around bf_crypt_encode(), thereby suggesting that
                      > it is indeed using the Output FeedBack mode.
                      >
                      > However that isn't actually true. The code isn't really clear but I
                      > think it seems most like CFB: the plaintext is XORed with the output
                      > from the block cypher and given back to the block cypher in the next
                      > block. This became visible only when I drew a picture and compared it
                      > with those on the wikipedia page.
                      >
                      > It looks like that without the macro "BF_OFB_UPDATE" the code would
                      > actually implement OFB.

                      Right, it looks like the code is doing CFB instead of OFB.

                      > > 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.
                      >
                      > Actually it can definitely be true. And that isn't due to a deficiency
                      > in Blowfish or its implementation, but when OFB mode is used. And as
                      > long as the code suggest that OFB indeed is used, this counts as a
                      > vulnerability in itself.
                      >
                      > As you can see at
                      > http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_feedback_.28OFB.29
                      > when decrypting in OFB mode, a corruption in one cyphertext block does
                      > *not* propagate to any next block! In effect, the block cypher is merely
                      > used to generate a stream of pseudo-random bits which are
                      > XORed with the plain text to generate the ciphertext.
                      >
                      > Which means that an attacker can trivially flip any bits in the file
                      > that (s)he wishes.

                      So, CFB is better than OFB? Then we are fine.

                      > Note I'm not a professional cryptographer, but I've made a few crypto
                      > thingies in the past and got lambasted for the stupid mistakes I made in
                      > them. This taught me that it is much more difficult to get it right
                      > than to get it wrong, and about some of the mistakes that any
                      > non-careful implementer oh so easily makes.
                      >
                      > I would suggest updating the terminology in blowfish.c, and then have
                      > another few people look at it to triple-check it.
                      >
                      > Oh, and I too think that decrypting to garbage without an error message
                      > is really the wrong thing to do.

                      It does make an attack more complicated. Even more so when compressing
                      the text before encrypting it.

                      --
                      hundred-and-one symptoms of being an internet addict:
                      142. You dream about creating the world's greatest web site.

                      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      \\\ an exciting new programming language -- http://www.Zimbu.org ///
                      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                      --
                      --
                      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.
                    Your message has been successfully submitted and would be delivered to recipients shortly.