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

patch for encryption, strengthened key with salt.

Expand Messages
  • Mosh
    Attaching patch7.zip encryption Key_strengthening Changes: 1 added 8 bytes salt to file header, 2. sha256_key takes password, salt, salt_len (salt is binary,
    Message 1 of 9 , May 30, 2010
    • 0 Attachment
      Attaching patch7.zip encryption Key_strengthening

      Changes:
      1 added 8 bytes salt to file header,
      2. sha256_key takes password, salt, salt_len (salt is binary, not
      null terminated)
      3. sha256_seed also generates salt along with iv.
      4. bf_key_init takes password and salt.
      5. bf_key_init converts ascii hex key[64] to binary key[32] (this
      change is independent of the 1..4 above)

      Also attached is vc-proj.zip (contains dsp and dsw project files).
      The HG repository didn't have these files, so I copied them from older
      older source tree.
      Might be useful to others on this list using vc++ on windows to debug.

      thanks
      mohsin.

      ===
      Changes are to these functions:

      -char_u *sha256_key __ARGS((char_u *buf));
      +char_u *sha256_key __ARGS((char_u *buf, char_u *salt, int salt_len));
      -void sha2_seed __ARGS((char_u header[], int header_len));
      +void sha2_seed __ARGS((char_u header[], int header_len, char_u
      salt[], int salt_len));
      -void bf_key_init __ARGS((char_u *password));
      +void bf_key_init __ARGS((char_u *password, char_u *salt, int salt_len));

      ====
      Archive: patch7.zip
      Length Method Size Cmpr Date Time CRC-32 Name
      -------- ------ ------- ---- ---------- ----- -------- ----
      0 Stored 0 0% 05-30-2010 16:18 00000000 patch7/
      22403 Defl:N 9436 58% 05-30-2010 16:15 c5f05ce7 patch7/blowfish.c
      269 Defl:N 149 45% 05-30-2010 14:35 7550dad0 patch7/blowfish.pro
      259837 Defl:N 74612 71% 05-30-2010 16:04 135cabf3 patch7/fileio.c
      14976 Defl:N 2044 86% 05-22-2010 18:19 fc01209c patch7/Make_ivc.dsp
      534 Defl:N 208 61% 03-15-2010 19:16 c76b6155 patch7/Make_ivc.dsw
      12513 Defl:N 3947 69% 05-30-2010 16:04 579b33d9 patch7/sha256.c
      437 Defl:N 208 52% 05-30-2010 15:06 338b6d4c patch7/sha256.pro
      9905 Defl:N 3109 69% 05-30-2010 16:17 23c0e6bd
      patch7/udiff-73hg-73hgm2.diff
      -------- ------- --- -------
      320874 93713 71% 9 files



      ====
      Archive: vc-proj.zip
      Length Method Size Cmpr Date Time CRC-32 Name
      -------- ------ ------- ---- ---------- ----- -------- ----
      14976 Defl:N 2044 86% 05-22-2010 18:19 fc01209c patch7/Make_ivc.dsp
      534 Defl:N 208 61% 03-15-2010 19:16 c76b6155 patch7/Make_ivc.dsw
      -------- ------- --- -------
      15510 2252 86% 2 files



      On Wed, May 26, 2010 at 1:50 AM, Bram Moolenaar <Bram@...> wrote:
      >
      > Mohsin wrote:
      >
      >> So I downloaded the source with hg, and built gvimd.exe with VC++.
      >>
      >> I see that vim only writes encrypted file with VimCrypt~01 version (I
      >> am looking at fileio.c)
      >> how do I get it to use VimCrypt~02 for writing new files.
      >
      >        :set cryptmethod=1
      >
      > Currently the default is still 0, to avoid people creating files they
      > can't uncrypt on another system.  I'm not sure when the default can be
      > 1.  Perhaps only in Vim 7.4.
      >
      >> I have another minor patch ready for
      >> http://en.wikipedia.org/wiki/Key_strengthening
      >> which I need to test a bit.
      >
      > OK, please send me a patch against the mercurial repository when you are
      > ready.
      >
      >> Minor build fix for vc++ was to comment out this line,
      >>   netbeans.c:369   // sock_errno =3D EINTR;  // sock_errno is a function
      >> (not an l-value) in win32.
      >
      > That was fixed, please "hg pull".
      >
      >
      > --
      > From "know your smileys":
      >  <|-) Chinese
      >  <|-( Chinese and doesn't like these kind of jokes
      >
      >  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
      > ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      > \\\        download, build and distribute -- http://www.A-A-P.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
    • Bram Moolenaar
      ... Can you explain what this does, how it makes the encryption stronger, and if there is any impact on performance? A link to a page that explains it would
      Message 2 of 9 , May 31, 2010
      • 0 Attachment
        Mohsin wrote:

        > Attaching patch7.zip encryption Key_strengthening
        >
        > Changes:
        > 1 added 8 bytes salt to file header,
        > 2. sha256_key takes password, salt, salt_len (salt is binary, not
        > null terminated)
        > 3. sha256_seed also generates salt along with iv.
        > 4. bf_key_init takes password and salt.
        > 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
        > change is independent of the 1..4 above)
        >
        > Also attached is vc-proj.zip (contains dsp and dsw project files).
        > The HG repository didn't have these files, so I copied them from older
        > older source tree.
        > Might be useful to others on this list using vc++ on windows to debug.

        Can you explain what this does, how it makes the encryption stronger,
        and if there is any impact on performance? A link to a page that
        explains it would be helpful.

        --
        hundred-and-one symptoms of being an internet addict:
        132. You come back and check this list every half-hour.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.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
      • Mosh
        ... Here is the doc for salting, this can be added to the code: http://en.wikipedia.org/wiki/Key_strengthening Its summary is: The salt is a random number
        Message 3 of 9 , May 31, 2010
        • 0 Attachment
          On Mon, May 31, 2010 at 9:17 AM, Bram Moolenaar <Bram@...> wrote:
          >
          > Mohsin wrote:
          >
          >> Attaching patch7.zip encryption Key_strengthening
          >>
          >> Changes:
          >> 1 added 8 bytes salt to file header,
          >> 2. sha256_key takes password, salt, salt_len  (salt is binary, not
          >> null terminated)
          >> 3. sha256_seed also generates salt along with iv.
          >> 4. bf_key_init takes password and salt.
          >> 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
          >> change is independent of the 1..4 above)
          >>
          >> Also attached is vc-proj.zip (contains dsp and dsw project files).
          >> The HG repository didn't have these files, so I copied them from older
          >> older source tree.
          >> Might be useful to others on this list using vc++ on windows to debug.
          >
          > Can you explain what this does, how it makes the encryption stronger,
          > and if there is any impact on performance?  A link to a page that
          > explains it would be helpful.

          Here is the doc for salting, this can be added to the code:

          http://en.wikipedia.org/wiki/Key_strengthening

          Its summary is:

          The salt is a random number concatenated to the password to create a
          one time key.

          This prevents someone from precomputing keys (dictionary),
          because the salt is a different in each file.

          The key computation is slowed down for offline attack;
          this prevents someone with the file+salt but not the password,
          from using brute force -
          That is they feed all passwords 'a', 'aa', ... but they should NOT
          have enough time to to try all 8 char passwords.

          ===
          Other docs that relate to this code:

          http://en.wikipedia.org/wiki/Blowfish_%28cipher%29
          http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation


          >
          > --
          > hundred-and-one symptoms of being an internet addict:
          > 132. You come back and check this list every half-hour.
          >
          >  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
          > ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          > \\\        download, build and distribute -- http://www.A-A-P.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
        • Bram Moolenaar
          ... Can we avoid the intermediate step with ascii hex? ... We already had the seed for this. The wiki page actually describes a method to feed the password
          Message 4 of 9 , May 31, 2010
          • 0 Attachment
            Mohsin wrote:

            > >> Attaching patch7.zip encryption Key_strengthening
            > >>
            > >> Changes:
            > >> 1 added 8 bytes salt to file header,
            > >> 2. sha256_key takes password, salt, salt_len (salt is binary, not
            > >> null terminated)
            > >> 3. sha256_seed also generates salt along with iv.
            > >> 4. bf_key_init takes password and salt.
            > >> 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
            > >> change is independent of the 1..4 above)

            Can we avoid the intermediate step with ascii hex?

            > >> Also attached is vc-proj.zip (contains dsp and dsw project files).
            > >> The HG repository didn't have these files, so I copied them from older
            > >> older source tree.
            > >> Might be useful to others on this list using vc++ on windows to debug.
            > >
            > > Can you explain what this does, how it makes the encryption stronger,
            > > and if there is any impact on performance? A link to a page that
            > > explains it would be helpful.
            >
            > Here is the doc for salting, this can be added to the code:
            >
            > http://en.wikipedia.org/wiki/Key_strengthening
            >
            > Its summary is:
            >
            > The salt is a random number concatenated to the password to create a
            > one time key.
            >
            > This prevents someone from precomputing keys (dictionary),
            > because the salt is a different in each file.

            We already had the seed for this. The wiki page actually describes a
            method to feed the password through an algorithm that costs time, to
            increase the time needed for a brute force attack.

            Instead of using both a seed and a salt, can we use one? Hmm, I suppose
            using two different strings adds to the strength.

            > The key computation is slowed down for offline attack;
            > this prevents someone with the file+salt but not the password,
            > from using brute force -
            > That is they feed all passwords 'a', 'aa', ... but they should NOT
            > have enough time to to try all 8 char passwords.
            >
            > ===
            > Other docs that relate to this code:
            >
            > http://en.wikipedia.org/wiki/Blowfish_%28cipher%29
            > http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

            OK. I'm not sure if we really need this for Vim, or perhaps in limited
            form. I would like this to work well on slow machines. One important
            difference from many other applications of cyphers is that Vim has no
            check if the correct key is used. The attacker has to know something
            that must exist in the file, literally. That also makes attacks a lot
            slower.

            You use a strengthen_key value of 1000. Why not 100 or 10000?
            Perhaps we should put this value in the header as well, so that we can
            change it over time?

            About the code: Please, please use the Vim formatting style.


            Another question: I would like to also encrypt the swapfile. The
            problem is that this is written and read in blocks of 4Kbyte or more.
            There is no predefined order in which to perform the I/O, thus each
            block must be crypted and decrypted by itself.

            What we could do is generate a seed or salt for each block, and store
            that in the pointer block that refers to the data block. We can
            generate a new seed each time a block is written. The pointer block
            must then also be written later. We do need to restart the encryption
            for each block though. I suppose there is no safe way to store the
            state of the crypter in the file so that we can continue from there.

            Another problem is when changing the key: we would need to read back all
            blocks with the old key and crypt them with the new key.

            --
            "The sun oozed over the horizon, shoved aside darkness, crept along the
            greensward, and, with sickly fingers, pushed through the castle window,
            revealing the pillaged princess, hand at throat, crown asunder, gaping
            in frenzied horror at the sated, sodden amphibian lying beside her,
            disbelieving the magnitude of the frog's deception, screaming madly,
            "You lied!"
            - Winner of the Bulwer-Lytton contest (San Jose State University),
            wherein one writes only the first line of a bad novel

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.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
          • Mosh
            ... Yes. key_strengthening is not really important. I was just going by the standard literature. ... Any value of similar magnitude would do; the wiki suggests
            Message 5 of 9 , Jun 1, 2010
            • 0 Attachment
              On Mon, May 31, 2010 at 12:17 PM, Bram Moolenaar <Bram@...> wrote:
              >
              > Mohsin wrote:
              >
              >> >> Attaching patch7.zip encryption Key_strengthening
              >> >>
              >> >> Changes:
              >> >> 1 added 8 bytes salt to file header,
              >> >> 2. sha256_key takes password, salt, salt_len  (salt is binary, not
              >> >> null terminated)
              >> >> 3. sha256_seed also generates salt along with iv.
              >> >> 4. bf_key_init takes password and salt.
              >> >> 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
              >> >> change is independent of the 1..4 above)
              >
              > Can we avoid the intermediate step with ascii hex?
              >
              >> >> Also attached is vc-proj.zip (contains dsp and dsw project files).
              >> >> The HG repository didn't have these files, so I copied them from older
              >> >> older source tree.
              >> >> Might be useful to others on this list using vc++ on windows to debug.
              >> >
              >> > Can you explain what this does, how it makes the encryption stronger,
              >> > and if there is any impact on performance?  A link to a page that
              >> > explains it would be helpful.
              >>
              >> Here is the doc for salting, this can be added to the code:
              >>
              >> http://en.wikipedia.org/wiki/Key_strengthening
              >>
              >> Its summary is:
              >>
              >> The salt is a random number concatenated to the password to create a
              >> one time key.
              >>
              >> This prevents someone from precomputing keys (dictionary),
              >> because the salt is a different in each file.
              >
              > We already had the seed for this.  The wiki page actually describes a
              > method to feed the password through an algorithm that costs time, to
              > increase the time needed for a brute force attack.
              >
              > Instead of using both a seed and a salt, can we use one?  Hmm, I suppose
              > using two different strings adds to the strength.
              >
              >> The key computation is slowed down for offline attack;
              >> this prevents someone with the file+salt but not the password,
              >> from using brute force -
              >> That is they feed all passwords 'a', 'aa', ... but they should NOT
              >> have enough time to to try all 8 char passwords.
              >>
              >> ===
              >> Other docs that relate to this code:
              >>
              >> http://en.wikipedia.org/wiki/Blowfish_%28cipher%29
              >> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
              >
              > OK.  I'm not sure if we really need this for Vim, or perhaps in limited
              > form.  I would like this to work well on slow machines.  One important
              > difference from many other applications of cyphers is that Vim has no
              > check if the correct key is used.  The attacker has to know something
              > that must exist in the file, literally.  That also makes attacks a lot
              > slower.

              Yes. key_strengthening is not really important.
              I was just going by the standard literature.

              >
              > You use a strengthen_key value of 1000.  Why not 100 or 10000?
              > Perhaps we should put this value in the header as well, so that we can
              > change it over time?

              Any value of similar magnitude would do; the wiki suggests 65000;
              Reason: Time to compute one key is feasible for a user, but
              time to compute for whole dictionary + salt is infeasible.

              >
              > About the code: Please, please use the Vim formatting style.

              I thought I did that, except that I used spaces instead of tabs.

              > Another question: I would like to also encrypt the swapfile.  The
              > problem is that this is written and read in blocks of 4Kbyte or more.
              > There is no predefined order in which to perform the I/O, thus each
              > block must be crypted and decrypted by itself.

              This can be done:

              a Use any key (password with/without salt) to init blowfish;
              and then call the blowfish to encrypt/decrypt blocks
              of 8 bytes of swap file.

              for i = 0 ; i < 4k/8 ; i+=8
              block[i*8..i*8+8] ^= bf_encrypt(integer i); // blowfish in CTR mode.

              CTR diagram is in here
              http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

              >
              > What we could do is generate a seed or salt for each block, and store
              > that in the pointer block that refers to the data block.  We can
              > generate a new seed each time a block is written.  The pointer block
              > must then also be written later.  We do need to restart the encryption
              > for each block though.  I suppose there is no safe way to store the
              > state of the crypter in the file so that we can continue from there.

              If you keep a constant salt + password, you get a session key,
              use that in bf_init, then you can just use the file offset:

              block[i] ^= bf_encrypt(offset)

              So any 8byte block can be encrypted/decrypted independently.

              >
              > Another problem is when changing the key: we would need to read back all
              > blocks with the old key and crypt them with the new key.

              Yes. Or keep a separate session key in memory for swap files.
              This would make it impossible to recover swap files in case of crash.

              Or keep the hashmap: swap -> key, and switch tp new
              keys lazily - during write.


              About random number usage:
              The random number for IV is generated using sha(loop time),
              this is good enough in practice. For better randomness,
              vim could measure the time deltas between user keystrokes (like pgp).


              thanks,
              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
            • Richard Hartmann
              ... Everything else being equal, it makes (slightly) more sense to prefix the salt, not to suffix it. Obviously, this is more important with ciphers than with
              Message 6 of 9 , Jun 2, 2010
              • 0 Attachment
                On Mon, May 31, 2010 at 20:06, Mosh <moshahmed@...> wrote:


                > http://en.wikipedia.org/wiki/Key_strengthening


                > The salt is a random number concatenated to the password to create a
                > one time key.

                Everything else being equal, it makes (slightly) more sense to prefix
                the salt, not to suffix it.
                Obviously, this is more important with ciphers than with hashes, but
                the basic point remains.


                > This prevents someone from precomputing keys (dictionary),
                > because the salt is a different in each file.

                Ideally, the salt would change every time the file is saved.


                Another trick, especially as there is no integrity control in
                Vim's encryption, would be to have an ever-changing prefix
                _within_ the file, perhaps even with unprintable bytecodes.

                That would make the typical high-speed attacks (only decrypt
                the first few bytes and go to the next key if you encounter
                any non-char sequences) a lot harder. On the other hand,
                this only works for files that are meant for humans and/or
                that are very liberal when parsing input.


                Richard

                --
                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
              • Mosh
                On Wed, Jun 2, 2010 at 12:44 PM, Richard Hartmann ... This is already the case, both the salt[8 bytes] and iv[8 bytes] are generated before each write/save
                Message 7 of 9 , Jun 2, 2010
                • 0 Attachment
                  On Wed, Jun 2, 2010 at 12:44 PM, Richard Hartmann
                  <richih.mailinglist@...> wrote:
                  > On Mon, May 31, 2010 at 20:06, Mosh <moshahmed@...> wrote:
                  >
                  >
                  >> http://en.wikipedia.org/wiki/Key_strengthening
                  >
                  >
                  >> The salt is a random number concatenated to the password to create a
                  >> one time key.
                  >
                  > Everything else being equal, it makes (slightly) more sense to prefix
                  > the salt, not to suffix it.
                  > Obviously, this is more important with ciphers than with hashes, but
                  > the basic point remains.
                  >
                  >
                  >> This prevents someone from precomputing keys (dictionary),
                  >> because the salt is a different in each file.
                  >
                  > Ideally, the salt would change every time the file is saved.

                  This is already the case, both the salt[8 bytes] and iv[8 bytes]
                  are generated before each write/save file.

                  To see it, save the file blowfish encrypted twice, and diff the hex dumps, e.g.

                  $ vim
                  edit some text .. and switch to new cryptmethod.
                  :X pass
                  :sav x
                  :sav y
                  :wq
                  od -c x > x1
                  od -c y > y1
                  vim -d x1 y1

                  almost all bytes will differ, except 12 byte signature.


                  >
                  >
                  > Another trick, especially as there is no integrity control in
                  > Vim's encryption, would be to have an ever-changing prefix
                  > _within_ the file, perhaps even with unprintable bytecodes.

                  I wrote some code to do this, but didn't add it to vim:

                  [header] [random string of random size][encrypted file][integrity
                  checksum][random string of random size]


                  > That would make the typical high-speed attacks (only decrypt
                  > the first few bytes and go to the next key if you encounter
                  > any non-char sequences) a lot harder. On the other hand,
                  > this only works for files that are meant for humans and/or
                  > that are very liberal when parsing input.
                  >
                  >
                  > Richard
                  >
                  > --
                  > 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 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
                • Bram Moolenaar
                  ... No answer on this question? ... I thought we already did that, only it s called seed in fileio.c ... I did some performance measurements. Crypting a 30
                  Message 8 of 9 , Jun 2, 2010
                  • 0 Attachment
                    Mohsin wrote:

                    > >> >> Attaching patch7.zip encryption Key_strengthening
                    > >> >>
                    > >> >> Changes:
                    > >> >> 1 added 8 bytes salt to file header,
                    > >> >> 2. sha256_key takes password, salt, salt_len (salt is binary, not
                    > >> >> null terminated)
                    > >> >> 3. sha256_seed also generates salt along with iv.
                    > >> >> 4. bf_key_init takes password and salt.
                    > >> >> 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
                    > >> >> change is independent of the 1..4 above)
                    > >
                    > > Can we avoid the intermediate step with ascii hex?

                    No answer on this question?

                    > >> >> Also attached is vc-proj.zip (contains dsp and dsw project files).
                    > >> >> The HG repository didn't have these files, so I copied them from older
                    > >> >> older source tree.
                    > >> >> Might be useful to others on this list using vc++ on windows to debug.
                    > >> >
                    > >> > Can you explain what this does, how it makes the encryption stronger,
                    > >> > and if there is any impact on performance? A link to a page that
                    > >> > explains it would be helpful.
                    > >>
                    > >> Here is the doc for salting, this can be added to the code:
                    > >>
                    > >> http://en.wikipedia.org/wiki/Key_strengthening
                    > >>
                    > >> Its summary is:
                    > >>
                    > >> The salt is a random number concatenated to the password to create a
                    > >> one time key.
                    > >>
                    > >> This prevents someone from precomputing keys (dictionary),
                    > >> because the salt is a different in each file.

                    I thought we already did that, only it's called "seed" in fileio.c

                    > > We already had the seed for this. The wiki page actually describes a
                    > > method to feed the password through an algorithm that costs time, to
                    > > increase the time needed for a brute force attack.
                    > >
                    > > Instead of using both a seed and a salt, can we use one? Hmm, I suppose
                    > > using two different strings adds to the strength.
                    > >
                    > >> The key computation is slowed down for offline attack;
                    > >> this prevents someone with the file+salt but not the password,
                    > >> from using brute force -
                    > >> That is they feed all passwords 'a', 'aa', ... but they should NOT
                    > >> have enough time to to try all 8 char passwords.
                    > >>
                    > >> ===
                    > >> Other docs that relate to this code:
                    > >>
                    > >> http://en.wikipedia.org/wiki/Blowfish_%28cipher%29
                    > >> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
                    > >
                    > > OK. I'm not sure if we really need this for Vim, or perhaps in limited
                    > > form. I would like this to work well on slow machines. One important
                    > > difference from many other applications of cyphers is that Vim has no
                    > > check if the correct key is used. The attacker has to know something
                    > > that must exist in the file, literally. That also makes attacks a lot
                    > > slower.
                    >
                    > Yes. key_strengthening is not really important.
                    > I was just going by the standard literature.

                    I did some performance measurements. Crypting a 30 Mbyte file just
                    takes a couple of seconds, let's say 10 Mbyte/sec. If 1 Kbyte is
                    sufficient to check for expected text, 10'000 passwords can be tried per
                    second. If we do 1000 rounds before starting on the text, we reduce
                    this to 5'000 passwords. Does not really help much, right?

                    It would make a difference if there was a check for correct password,
                    e.g., with a few bytes at the start of the file. But we don't have that
                    (intentionally).

                    Well, suppose the attacker knows something about the file, e.g., that it
                    starts with the name of the company or some header, then perhaps the
                    check can be done in 20 bytes or so. Going to 1020 bytes is then a slow
                    down of a factor 1000 / 20 = 50. That helps, but is this significant?

                    > > You use a strengthen_key value of 1000. Why not 100 or 10000?
                    > > Perhaps we should put this value in the header as well, so that we can
                    > > change it over time?
                    >
                    > Any value of similar magnitude would do; the wiki suggests 65000;
                    > Reason: Time to compute one key is feasible for a user, but
                    > time to compute for whole dictionary + salt is infeasible.

                    Let's assume an old computer is 100 times slower than mine, thus instead
                    of 10 Mbyte/sec it does 100 Kbyte/sec. 65000 is then about a second.
                    A small price to pay (keep in mind that you have to type the password,
                    this will take a few seconds). Perhaps we can use a value of 10000.

                    > > About the code: Please, please use the Vim formatting style.
                    >
                    > I thought I did that, except that I used spaces instead of tabs.

                    In some parts spaces in expressions were missing.

                    > > Another question: I would like to also encrypt the swapfile. The
                    > > problem is that this is written and read in blocks of 4Kbyte or more.
                    > > There is no predefined order in which to perform the I/O, thus each
                    > > block must be crypted and decrypted by itself.
                    >
                    > This can be done:
                    >
                    > a Use any key (password with/without salt) to init blowfish;
                    > and then call the blowfish to encrypt/decrypt blocks
                    > of 8 bytes of swap file.
                    >
                    > for i = 0 ; i < 4k/8 ; i+=8
                    > block[i*8..i*8+8] ^= bf_encrypt(integer i); // blowfish in CTR mode.
                    >
                    > CTR diagram is in here
                    > http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
                    >
                    > >
                    > > What we could do is generate a seed or salt for each block, and store
                    > > that in the pointer block that refers to the data block. We can
                    > > generate a new seed each time a block is written. The pointer block
                    > > must then also be written later. We do need to restart the encryption
                    > > for each block though. I suppose there is no safe way to store the
                    > > state of the crypter in the file so that we can continue from there.
                    >
                    > If you keep a constant salt + password, you get a session key,
                    > use that in bf_init, then you can just use the file offset:
                    >
                    > block[i] ^= bf_encrypt(offset)
                    >
                    > So any 8byte block can be encrypted/decrypted independently.

                    The crypt_encode() and crypt_decode() functions can now be used, right?
                    I moved some code around to make it faster (avoid calling a function for
                    every byte).

                    > > Another problem is when changing the key: we would need to read back all
                    > > blocks with the old key and crypt them with the new key.
                    >
                    > Yes. Or keep a separate session key in memory for swap files.
                    > This would make it impossible to recover swap files in case of crash.
                    >
                    > Or keep the hashmap: swap -> key, and switch tp new
                    > keys lazily - during write.

                    Hmm, using a seed key, generated new for each swap file, plus the
                    password, plus the byte offset in the file. Sounds like this would
                    work. I suppose this does not make it easier for an attacker to guess
                    the key.

                    > About random number usage:
                    > The random number for IV is generated using sha(loop time),
                    > this is good enough in practice. For better randomness,
                    > vim could measure the time deltas between user keystrokes (like pgp).

                    I already changed it to use micro seconds instead of time(). A second
                    timestamp is too predictable.

                    - Bram

                    --
                    hundred-and-one symptoms of being an internet addict:
                    141. You'd rather go to http://www.weather.com/ than look out your window.

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ download, build and distribute -- http://www.A-A-P.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
                  • Mosh
                    ... Yes, the ascii conversion can be avoided. I wanted to do the same. The reason ascii was used, was to be make keys compatible with string passwords of vim.
                    Message 9 of 9 , Jun 2, 2010
                    • 0 Attachment
                      On Wed, Jun 2, 2010 at 1:52 PM, Bram Moolenaar <Bram@...> wrote:
                      >
                      > Mohsin wrote:
                      >
                      >> >> >> Attaching patch7.zip encryption Key_strengthening
                      >> >> >>
                      >> >> >> Changes:
                      >> >> >> 1 added 8 bytes salt to file header,
                      >> >> >> 2. sha256_key takes password, salt, salt_len  (salt is binary, not
                      >> >> >> null terminated)
                      >> >> >> 3. sha256_seed also generates salt along with iv.
                      >> >> >> 4. bf_key_init takes password and salt.
                      >> >> >> 5. bf_key_init converts ascii hex key[64] to binary key[32] (this
                      >> >> >> change is independent of the 1..4 above)
                      >> >
                      >> > Can we avoid the intermediate step with ascii hex?
                      >
                      > No answer on this question?

                      Yes, the ascii conversion can be avoided. I wanted to do the same.

                      The reason ascii was used, was to be make keys compatible with string
                      passwords of vim.

                      Since binary keys can contain '\0' null bytes, some keys would look
                      like empty password == ""
                      and no encryption would take place. This will happen often (with
                      probability 1/256).

                      To handle null bytes case, you could track the key_length separately
                      (or hardcode the len,
                      and keep a bool to indicate no-password).

                      >
                      >> >> >> Also attached is vc-proj.zip (contains dsp and dsw project files).
                      >> >> >> The HG repository didn't have these files, so I copied them from older
                      >> >> >> older source tree.
                      >> >> >> Might be useful to others on this list using vc++ on windows to debug.
                      >> >> >
                      >> >> > Can you explain what this does, how it makes the encryption stronger,
                      >> >> > and if there is any impact on performance?  A link to a page that
                      >> >> > explains it would be helpful.
                      >> >>
                      >> >> Here is the doc for salting, this can be added to the code:
                      >> >>
                      >> >> http://en.wikipedia.org/wiki/Key_strengthening
                      >> >>
                      >> >> Its summary is:
                      >> >>
                      >> >> The salt is a random number concatenated to the password to create a
                      >> >> one time key.
                      >> >>
                      >> >> This prevents someone from precomputing keys (dictionary),
                      >> >> because the salt is a different in each file.
                      >
                      > I thought we already did that, only it's called "seed" in fileio.c

                      That 'seed' in fileio is the IV (initialization vector),
                      we should rename this variable to crypt_initialization_vector or something
                      to be clear.

                      The doc on IV is here: http://en.wikipedia.org/wiki/Initialization_vector

                      >
                      >> > We already had the seed for this.  The wiki page actually describes a
                      >> > method to feed the password through an algorithm that costs time, to
                      >> > increase the time needed for a brute force attack.
                      >> >
                      >> > Instead of using both a seed and a salt, can we use one?  Hmm, I suppose
                      >> > using two different strings adds to the strength.
                      >> >
                      >> >> The key computation is slowed down for offline attack;
                      >> >> this prevents someone with the file+salt but not the password,
                      >> >> from using brute force -
                      >> >> That is they feed all passwords 'a', 'aa', ... but they should NOT
                      >> >> have enough time to to try all 8 char passwords.
                      >> >>
                      >> >> ===
                      >> >> Other docs that relate to this code:
                      >> >>
                      >> >> http://en.wikipedia.org/wiki/Blowfish_%28cipher%29
                      >> >> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
                      >> >
                      >> > OK.  I'm not sure if we really need this for Vim, or perhaps in limited
                      >> > form.  I would like this to work well on slow machines.  One important
                      >> > difference from many other applications of cyphers is that Vim has no
                      >> > check if the correct key is used.  The attacker has to know something
                      >> > that must exist in the file, literally.  That also makes attacks a lot
                      >> > slower.
                      >>
                      >> Yes. key_strengthening is not really important.
                      >> I was just going by the standard literature.
                      >
                      > I did some performance measurements.  Crypting a 30 Mbyte file just
                      > takes a couple of seconds, let's say 10 Mbyte/sec.  If 1 Kbyte is
                      > sufficient to check for expected text, 10'000 passwords can be tried per
                      > second.  If we do 1000 rounds before starting on the text, we reduce
                      > this to 5'000 passwords.  Does not really help much, right?
                      >
                      > It would make a difference if there was a check for correct password,
                      > e.g., with a few bytes at the start of the file.  But we don't have that
                      > (intentionally).
                      >
                      > Well, suppose the attacker knows something about the file, e.g., that it
                      > starts with the name of the company or some header, then perhaps the
                      > check can be done in 20 bytes or so.  Going to 1020 bytes is then a slow
                      > down of a factor 1000 / 20 = 50.  That helps, but is this significant?

                      Good point,

                      note: Instead of looking for a company header in the decrypted block,
                      people would look for _all_ ascii chars, i.e. if all high bits are 0
                      in the decrypted text, then
                      it is an ascii file and the key is correct with high probability
                      (1-1/2**textsize).


                      >> > You use a strengthen_key value of 1000.  Why not 100 or 10000?
                      >> > Perhaps we should put this value in the header as well, so that we can
                      >> > change it over time?
                      >>
                      >> Any value of similar magnitude would do; the wiki suggests 65000;
                      >> Reason: Time to compute one key is feasible for a user, but
                      >> time to compute for whole dictionary + salt is infeasible.
                      >
                      > Let's assume an old computer is 100 times slower than mine, thus instead
                      > of 10 Mbyte/sec it does 100 Kbyte/sec. 65000 is then about a second.
                      > A small price to pay (keep in mind that you have to type the password,
                      > this will take a few seconds).  Perhaps we can use a value of 10000.
                      >
                      >> > About the code: Please, please use the Vim formatting style.
                      >>
                      >> I thought I did that, except that I used spaces instead of tabs.
                      >
                      > In some parts spaces in expressions were missing.
                      >
                      >> > Another question: I would like to also encrypt the swapfile.  The
                      >> > problem is that this is written and read in blocks of 4Kbyte or more.
                      >> > There is no predefined order in which to perform the I/O, thus each
                      >> > block must be crypted and decrypted by itself.
                      >>
                      >> This can be done:
                      >>
                      >>   a  Use any key (password with/without salt) to init blowfish;
                      >>       and then call the blowfish to encrypt/decrypt blocks
                      >>      of 8 bytes of swap file.
                      >>
                      >>       for i = 0 ; i < 4k/8 ; i+=8
                      >>          block[i*8..i*8+8] ^= bf_encrypt(integer i);  // blowfish in CTR mode.
                      >>
                      >>      CTR diagram is in here
                      >>      http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
                      >>
                      >> >
                      >> > What we could do is generate a seed or salt for each block, and store
                      >> > that in the pointer block that refers to the data block.  We can
                      >> > generate a new seed each time a block is written.  The pointer block
                      >> > must then also be written later.  We do need to restart the encryption
                      >> > for each block though.  I suppose there is no safe way to store the
                      >> > state of the crypter in the file so that we can continue from there.
                      >>
                      >> If you keep a constant salt + password, you get a session key,
                      >> use that in bf_init, then you can just use the file offset:
                      >>
                      >>    block[i] ^= bf_encrypt(offset)
                      >>
                      >> So any 8byte block can be encrypted/decrypted independently.
                      >
                      > The crypt_encode() and crypt_decode() functions can now be used, right?
                      > I moved some code around to make it faster (avoid calling a function for
                      > every byte).

                      Yes, I just had a look at crypt_encode(), it looks good. It can be used.
                      Just remember call bf_ofb_init(iv, iv_len) to set it up, before using
                      it on different files.


                      hope I covered all your questions.
                      --
                      mohsin


                      >
                      >> > Another problem is when changing the key: we would need to read back all
                      >> > blocks with the old key and crypt them with the new key.
                      >>
                      >> Yes. Or keep a separate session key in memory for swap files.
                      >> This would make it impossible to recover swap files in case of crash.
                      >>
                      >> Or keep the hashmap: swap -> key, and switch tp new
                      >> keys lazily - during write.
                      >
                      > Hmm, using a seed key, generated new for each swap file, plus the
                      > password, plus the byte offset in the file.  Sounds like this would
                      > work.  I suppose this does not make it easier for an attacker to guess
                      > the key.
                      >
                      >> About random number usage:
                      >> The random number for IV is generated using sha(loop time),
                      >> this is good enough in practice. For better randomness,
                      >> vim could measure the time deltas between user keystrokes (like pgp).
                      >
                      > I already changed it to use micro seconds instead of time().  A second
                      > timestamp is too predictable.
                      >
                      > - Bram
                      >
                      > --
                      > hundred-and-one symptoms of being an internet addict:
                      > 141. You'd rather go to http://www.weather.com/ than look out your window.
                      >
                      >  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
                      > ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                      > \\\        download, build and distribute -- http://www.A-A-P.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
                    Your message has been successfully submitted and would be delivered to recipients shortly.