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

Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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.