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

Re: Encryption: Vim should use authenticated encryption mode

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.