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

Encryption: Vim should use authenticated encryption mode

Expand Messages
  • Ulrik
    Hi, The blowfish encryption mode is vulnerable (not to revelation of the plaintext), but the encryption is not checked for integrity or authenticity. This
    Message 1 of 22 , Feb 14, 2013
    • 0 Attachment
      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.

      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.

      HTH,
      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.
    • Bram Moolenaar
      ... 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
      Message 2 of 22 , Feb 14, 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.

        --
        Communication is one of the most compli..., eh, well, it's hard.
        You know what I mean. Not?

        /// 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.
      • Taylor Hedberg
        ... Also, if you just need to ensure the integrity of the encrypted file, you could always use an external tool like gpg to sign it. That doesn t really need
        Message 3 of 22 , Feb 14, 2013
        • 0 Attachment
          Bram Moolenaar, Thu 2013-02-14 @ 22:08:21+0100:
          > 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.

          Also, if you just need to ensure the integrity of the encrypted file,
          you could always use an external tool like gpg to sign it. That doesn't
          really need to be built into Vim, in my opinion.
        • Ulrik
          ... 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
          Message 4 of 22 , Feb 14, 2013
          • 0 Attachment
            On 2013-02-14 22:08, 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.

            HTH,
            ulrik

            PS. the password is 'goodenough' literally.

            --
            --
            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
            Ulrik, Any one random bit flip will cause to one block (8 bytes) to be corrupted at that point, and then all bytes thereafter will be corrupted. Not just 1
            Message 5 of 22 , Feb 14, 2013
            • 0 Attachment
              Ulrik,

              Any one random bit flip will cause to one block (8 bytes) to be
              corrupted at that point,
              and then all bytes thereafter will be corrupted. Not just 1 bit
              corruption in encrypted text.

              And if you encrypt two text files with 1 bit difference, they should
              be completely
              different when encrypted. Even same text file will come out different
              each time it is
              written encrypted. Because a random seed is also used.

              Let me do more tests, and check how you got 1 bit difference. I am
              using an older gvim73,
              that I compiled myself.

              thanks for the report,
              mohsin

              On Fri, Feb 15, 2013 at 5:37 AM, Ulrik <ulrik.sverdrup@...> wrote:
              > On 2013-02-14 22:08, 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.
              >
              > HTH,
              > ulrik
              >
              > PS. the password is 'goodenough' literally.
              >
              > --
              > --
              > 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.
            • Ulrik
              Hi, ... This is my experience too. ... But not this! ... Just one 1 bit change works fine if you modify near the end of the file. -ulrik ... -- -- You received
              Message 6 of 22 , Feb 14, 2013
              • 0 Attachment
                Hi,

                On 2013-02-15 03:05, Mosh wrote:
                > Ulrik,
                >
                > Any one random bit flip will cause to one block (8 bytes) to be
                > corrupted at that point,

                This is my experience too.

                > and then all bytes thereafter will be corrupted.

                But not this!

                > Not just 1 bit
                > corruption in encrypted text.

                Just one 1 bit change works fine if you modify near the end of the file.

                -ulrik

                >
                > And if you encrypt two text files with 1 bit difference, they should
                > be completely
                > different when encrypted. Even same text file will come out different
                > each time it is
                > written encrypted. Because a random seed is also used.
                >
                > Let me do more tests, and check how you got 1 bit difference. I am
                > using an older gvim73,
                > that I compiled myself.
                >
                > thanks for the report,
                > mohsin

                --
                --
                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.
              • 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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.