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

Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • Tim Starling
    ... There s a lot of exploitable redundancy in a typical text file. For English text, you can just check if MSB of each byte is zero. The computational
    Message 1 of 22 , Feb 14, 2013
    • 0 Attachment
      On 15/02/13 08:08, Bram Moolenaar wrote:
      >
      > 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.

      There's a lot of exploitable redundancy in a typical text file. For
      English text, you can just check if MSB of each byte is zero. The
      computational requirements are probably lower than verifying a MAC.
      You would need a very large password before similarly large candidate
      passwords started generating ASCII text, and if the password was so
      large, brute force wouldn't be a problem.

      You could devise a scheme involving compression to reduce the amount
      of redundancy in the message. But key strengthening (PBKDF2 etc.) is
      probably a more robust way to mitigate brute force attacks.

      -- Tim Starling

      --
      --
      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
      Key strengthening is done in vim73. Compression would be nice before encryption; Alternatively you can just use gpg or pgp (compression, encryption, mac
      Message 2 of 22 , Feb 14, 2013
      • 0 Attachment
        Key strengthening is done in vim73.

        Compression would be nice before encryption; Alternatively you can just use
        gpg or pgp (compression, encryption, mac signatures, multiple keys),
        there was a vim plugin to do that.


        On Fri, Feb 15, 2013 at 11:10 AM, Tim Starling <tstarling@...> wrote:
        > On 15/02/13 08:08, Bram Moolenaar wrote:
        >>
        >> 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.
        >
        > There's a lot of exploitable redundancy in a typical text file. For
        > English text, you can just check if MSB of each byte is zero. The
        > computational requirements are probably lower than verifying a MAC.
        > You would need a very large password before similarly large candidate
        > passwords started generating ASCII text, and if the password was so
        > large, brute force wouldn't be a problem.
        >
        > You could devise a scheme involving compression to reduce the amount
        > of redundancy in the message. But key strengthening (PBKDF2 etc.) is
        > probably a more robust way to mitigate brute force attacks.
        >
        > -- Tim Starling
        >
        > --
        > --
        > 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.
      • MacDonald, Stuart
        From: Ulrik ... 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
        Message 3 of 22 , Feb 15, 2013
        • 0 Attachment
          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.
        • Ulrik
          ... 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
          Message 4 of 22 , Feb 15, 2013
          • 0 Attachment
            On 2013-02-15 16:34, MacDonald, Stuart wrote:
            > From: Ulrik
            >> Sent: February-14-13 1:00 PM
            >> The blowfish encryption mode is vulnerable (not to revelation of the
            >> plaintext), but the encryption is not checked for integrity or
            >
            > I suspect the real problem is a weakness in Vim's blowfish
            > implementation.
            >
            > But yes, I can reproduce this with gvim73_46.exe on
            > Win7 64-bit Enterprise.
            >
            >> authenticity. This means that someone might corrupt the encrypted file
            >> (hexedit or similar), and vim will decrypt it without notice of error or
            >> warning.
            >
            > This isn't supposed to happen. A strong encryption algorithm will
            > render completely different crypt text for even a single bit change in
            > the plaintext, and, a single bit change in the crypt text is supposed
            > to decrypt to corrupt plaintext.
            >

            I think this is your misconception. It can't strictly be true, because
            the uncorrupted prefix of the file will always decrypt ok. To truly
            render the *whole* decryption corrupt when the ciphertext is altered,
            that would require a multi-pass encryption algorithm.

            I modern crypto the error propagation and error detection discussions
            have totally vanished and authenticated encryption has taken its place;
            the new paradigm requires verified authenticity and integrity or
            discarding the message!

            I agree that Vim might have implementation issues. I have looked into
            the code and it says Blowfish with OFB mode however I cannot get the
            code or the behavior to line up with any block cipher mode I know of!

            >> This attack allows someone to modfiy encrypted files so that the owner
            >> doesn't notice. With sufficient tries or skill it might be possible to
            >> change a file's values in a predictable way at a certain offset.
            >
            > Agreed that someone can modify a VimCrypt file and have the
            > modification propagate into the plain text. However, for this to be a
            > useful attack I think that the plaintext already needs to be known
            > which is unlikely, and if it is known, given the plaintext and the
            > crypttext, it won't take to long to find the key, and then you can
            > make all the changes you want.
            >
            > I'm more concerned that this indicates there is a bug in Vim's
            > blowfish implementation and that will allow keys to be recovered more
            > easily. *That's* a big problem.
            >
            >> The solution is an authenticated encryption mode. The common way to do
            >
            > Perhaps, but only if this effect turns out to be endemic in blowfish
            > and not a result of the implementation. I feel strongly that we need
            > to examine the implementation first.
            >
            >> key. This code will detect the previous attack case, and additionally it
            >> allows vim to detect that the wrong password was entered. Security
            >
            > When the wrong password is entered the file decrypts to garbage, as it
            > should. There's no need to through an error there. If the file is
            > corrupted (as per your test or disk failure or cosmic ray) then it is
            > supposed to decrypt to garbage.

            Taken together, I think this is ridiculous. It is bad usability to give
            the user garbage output, as mistyped keys will happen to anyone. Instead
            you give them the opportunity to absent-mindedly save the garbage
            (destroying their data), or confusing them.

            >
            > I don't see a need for an authentication scheme, but then, I'm not a
            > security programmer by profession so I'm a novice and could be
            > incorrect.
            >
            > ...Stu
            >

            I'm not a crypto professional, and so I have respect for the ample
            documentation you can find about current best practice, and if Vim wants
            to go forward with a better encryption scheme, we must absolutely
            respect these practices.

            -ulrik

            --
            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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.