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

RE: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • MacDonald, Stuart
    From: Ulrik ... I can confirm that several smaller test cases fail; details below. ... In the future sending a precise list of steps to reproduce the problem
    Message 1 of 22 , Feb 15, 2013
    • 0 Attachment
      From: Ulrik
      > Sent: February-14-13 7:08 PM
      >
      > Using Vim 7.3 patches 1-547, this is not true, and it is trivially
      > testable (otherwise I would not have claimed it).

      I can confirm that several smaller test cases fail; details below.

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

      In the future sending a precise list of steps to reproduce the problem
      is a much better bug report than a vague set of instructions and a
      couple of file contents. To be honest, I was nervous using vim on your
      file below because you could have been trying to exploit an unknown
      security bug in vim. _Reporting_ a security bug would have been a
      clever bit of social engineering. Please note, I'm not trying to say
      anything about you or your intentions, just trying to describe my
      state of thought at the time. Your file contents appear to me to be
      good and non-malicious.

      The original file contents are <<EOF

      This is encrypted text.
      This is encrypted text.
      This is encrypted text.
      This is encrypted text.
      This is encrypted text.

      I owe you 200 USD.
      EOF

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

      Confirmed. Sadly. :-(

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

      You are correct. I have only tested altering the 9th last byte in the
      crypttext. Why did you pick that byte to modify?

      Vim needs more testing on this I think:
      - what happens when bytes other than the 9th last are modified?
      - exactly how much modification can be done before the file decrypts
      to garbage like it's supposed to
      - is there a range of bytes that are affected?
      - are certain keys affected? Or all keys?
      - is it something about the structure of the plaintext? The repetion
      or the small size?
      - what other characteristics of the bug can be determined?
      - are other crypt methods affected?

      I have tested tese contents <<EOF
      adsfasdfasdfasdfasdf
      asdmxzcvzxcvsdf980890asdf
      sdafknzxclv890asdf90uamsdfm
      xzcvklsadfnlasdf0

      1,211.98 is my tax refund this year.
      EOF

      by doing
      - vim -u NONE -U NONE S
      - enter the text above
      - :set cm=blowfish
      - :X
      - correcthorsebatterystaple
      - <confirm key>
      - :x

      xxd < S > S.xxd gives me:

      0000000: 5669 6d43 7279 7074 7e30 3221 244b 0178 VimCrypt~02!$K.x
      0000010: 2f63 cde0 50e2 b48d 5085 57c1 659a 4e03 /c..P...P.W.e.N.
      0000020: a08e c4e6 658d 5903 a08e c4e6 658d 5903 ....e.Y.....e.Y.
      0000030: ccf7 c1f3 6093 451f a28b daf8 6788 4e01 ....`.E.....g.N.
      0000040: a7c4 98b0 3cc7 0d04 b299 c68d 0e8d 5904 ....<.........Y.
      0000050: a796 cefa 7c9d 5113 f9c4 90e1 ab45 1fd6 ....|.Q......E..
      0000060: 39d9 8e01 5e0f 2faf 930f 2eaa 4396 2b44 9...^./.....C.+D
      0000070: f817 8a97 d8ae d153 ee24 b879 ab76 9ae5 .......S.$.y.v..
      0000080: b462 33e5 d9a5 26ba 2771 451a 59a8 012b .b3...&.'qE.Y..+
      0000090: 63d4 af6d 092c 1cda 5fb7 2bd9 a568 a349 c..m.,.._.+..h.I
      00000a0: e794 ab16 dc .....

      I've done this exact set of text a few times, and the crypttext is
      different each time as it should be. It's easiest if one does the
      encryption until the 9th last byte has the MSB set, that way you don't
      have to fiddle with the ascii representation at the end of the line,
      just change the hex value. Here it's offset 0x9c which is 0xa5.

      Then I do:

      - vim S.xxd
      - alter the value at 0x9c
      - :x
      - xxd -r < S.xxd > S
      - vim -u NONE -U NONE S
      - correcthorsebatterystaple
      - note the last line is alterated from "this year" to something:

      0xa0 == thiv
      0xa1 == thiw
      0xa2 == thit
      0xa3 == thiu
      0xa4 == thir
      0xa5 == this
      0xa6 == thip
      0xa7 == thiq
      0xa8 == thi~
      0xa9 == thi\0x7f
      0xaa == thi|
      0xab == thi}
      0xac == thiz
      0xad == thi{
      0xae == thix
      0xaf == thiy

      0xaa is a 4 bit change. This problem is bigger than single bit flips.
      The sharp-eyed will note the pattern in the incorrect text, which I
      expect is a direct result of a flaw in the blowfish implementation.

      Altering the high nibble also produces the incorrect behaviour (being
      careful to also alter the ascii character at the end of the line):

      0xb5 == thic
      0x55 == thi\0x83
      0x5a == thi\0x8c

      0x5a is an 8 bit difference. That's not insignificant.

      ...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.
    • MacDonald, Stuart
      From: Ulrik ... I did say I m a novice in this area. :-) The prefix argument is a good point. ...Stu -- -- You received this message from the vim_dev
      Message 2 of 22 , Feb 15, 2013
      • 0 Attachment
        From: Ulrik
        > Sent: February-15-13 11:57 AM
        >
        > On 2013-02-15 16:34, MacDonald, Stuart wrote:
        > > 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 did say I'm a novice in this area. :-) The prefix argument is a good
        point.

        ...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.
      • Ben Fritz
        ... I kind of like this idea, however, the point of Vim s encryption is not so you can send somebody a file and have them know it has not been modified. For
        Message 3 of 22 , Feb 15, 2013
        • 0 Attachment
          On Thursday, February 14, 2013 11:59:48 AM UTC-6, Ulrik wrote:
          > Hi,
          >
          >
          >
          > 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.
          >
          >

          I kind of like this idea, however, the point of Vim's encryption is not so you can send somebody a file and have them know it has not been modified. For this, you would need authentication as you say. The point of Vim's encryption is so that somebody who somehow gains access to a copy of a sensitive file (or somebody who hops on your computer while you step out a bit) can't SEE sensitive data.

          If an attacker has write access to your sensitive files, you have other problems.

          --
          --
          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
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.