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

Vim Crypto package

Expand Messages
  • Rajendra Sansare
    Hullo vim developers, I am new to this list. I am implementing a cryptography package for vim using block cipher Rijndael with additional mechanisms for data
    Message 1 of 9 , Oct 24, 2002
      Hullo vim developers,

      I am new to this list.

      I am implementing a cryptography package for vim using block
      cipher Rijndael with additional mechanisms for data integrity,
      user authentication and non repudiation. I am using the source
      code for version 6.0 .

      I have some doubts regarding the earlier crypto implementation
      (by Mohsin Ahmed , as listed in misc2.c).

      1) Is the data structure curbuf where the cryptkey is stored in
      field b_p_key, ever written out to the disk, or is the memory
      page containing buf_T instances memory locked.

      2)If the encrypted document is to be signed by a digital
      signature(GPG), should the signing and verification take place
      throuch calls in vim before decryption or externally. I ask this
      specifically because vim recognizes encrypted files by checking
      for "VimCrypt~01!", since addition of digital signature(plain
      ascii armor) might add some text before "VimCrypt~01!".

      Could someone help me out ?

      Thank You,

      rajs
    • Bram Moolenaar
      ... Sounds interesting. Would be tough to make it really secure. ... It s probably swapped to disk, like with all virtual memory. That s not really unsafer,
      Message 2 of 9 , Oct 24, 2002
        Rajendra Sansare wrote:

        > I am implementing a cryptography package for vim using block
        > cipher Rijndael with additional mechanisms for data integrity,
        > user authentication and non repudiation. I am using the source
        > code for version 6.0 .

        Sounds interesting. Would be tough to make it really secure.

        > I have some doubts regarding the earlier crypto implementation
        > (by Mohsin Ahmed , as listed in misc2.c).
        >
        > 1) Is the data structure curbuf where the cryptkey is stored in
        > field b_p_key, ever written out to the disk, or is the memory
        > page containing buf_T instances memory locked.

        It's probably swapped to disk, like with all virtual memory. That's not
        really unsafer, since root can read your memory just as well as the swap
        space. If you want against protection to people who can get their hands
        on the disk you have quite a bit of work to do.

        > 2)If the encrypted document is to be signed by a digital
        > signature(GPG), should the signing and verification take place
        > throuch calls in vim before decryption or externally. I ask this
        > specifically because vim recognizes encrypted files by checking
        > for "VimCrypt~01!", since addition of digital signature(plain
        > ascii armor) might add some text before "VimCrypt~01!".

        It should be symmetrical: if you add a signature somewhere, removing it
        should be done in a similar place at the other side. This means either
        signing it first and then crypting it, or the other way around. If
        adding a signature is done last, before writing the file, this would
        require some checks to recognize the signature when reading the file
        back in.

        --
        LAUNCELOT: At last! A call! A cry of distress ...
        (he draws his sword, and turns to CONCORDE)
        Concorde! Brave, Concorde ... you shall not have died in vain!
        CONCORDE: I'm not quite dead, sir ...
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.vim.org \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      • Glenn Maynard
        ... You can flag memory as unswappable on any secure OS. GPG probably does this, though probably only for Unix. If I want a document encrypted, I don t ever
        Message 3 of 9 , Oct 25, 2002
          On Thu, Oct 24, 2002 at 08:51:02PM +0200, Bram Moolenaar wrote:
          > It's probably swapped to disk, like with all virtual memory. That's not
          > really unsafer, since root can read your memory just as well as the swap
          > space. If you want against protection to people who can get their hands
          > on the disk you have quite a bit of work to do.

          You can flag memory as unswappable on any secure OS. GPG probably does
          this, though probably only for Unix.

          If I want a document encrypted, I don't ever want it going to the disk
          unencrypted. For example, I might encrypt a sensitive document in my
          home directory to keep it safe from either system compromise (someone
          gets access to my home directory) or hardware compromise (someone steals
          my computer). Having a copy lying around in the swapfile defeats this
          entirely.

          Of course, you'd have to be very careful to be sure you only access
          copies of this data with apps that are smart enough to put it in
          unswappable memory, including the terminal. It might be a futile task.
          However, the facilities are there.

          --
          Glenn Maynard
        • Rajendra Sansare
          ... A safe approach would be to always decrypt only a small portion of the encrypted buffer at a time. But this may be too costly in terms of response time to
          Message 4 of 9 , Oct 25, 2002
            On Thu, 24 Oct 2002, Bram Moolenaar wrote:

            >
            > It's probably swapped to disk, like with all virtual memory. That's not
            > really unsafer, since root can read your memory just as well as the swap
            > space. If you want against protection to people who can get their hands
            > on the disk you have quite a bit of work to do.
            >

            A safe approach would be to always decrypt only a small portion of the
            encrypted buffer at a time. But this may be too costly in terms of
            response time to the user and resources.

            Also the key obtained from the user is never stored in plaintext.
            But that brings up the question of the key which encrypts the users key,
            or rather "who watches the watchers?".

            > > 2)If the encrypted document is to be signed by a digital
            > > signature(GPG), should the signing and verification take place
            > > throuch calls in vim before decryption or externally. I ask this
            > > specifically because vim recognizes encrypted files by checking
            > > for "VimCrypt~01!", since addition of digital signature(plain
            > > ascii armor) might add some text before "VimCrypt~01!".
            >
            > It should be symmetrical: if you add a signature somewhere, removing it
            > should be done in a similar place at the other side. This means either
            > signing it first and then crypting it, or the other way around. If
            > adding a signature is done last, before writing the file, this would
            > require some checks to recognize the signature when reading the file
            > back in.
            >

            I feel that signing after encryption is necessary. I am using GPG for the
            signing purpose since its widely used on Linux like vim. GPG offers two
            modes of signature, one is detached signature and an appended plaintext
            (ascii armor) signature. In case of ascii armor , the signature check
            would take place before the file is read, because it would need
            editing(removal of the signature before decryption).

            Also locking memory pages would result in performance degradation for a
            large file and a machine with low memory.

            So is there any way in which the file would be read in encrypted form in
            the buffer, and then a memory location be alotted and small portions of
            the buffer be decrypted always overwriting the contents of the allocated
            memory area. (All this without too much of a digress from the current
            procedure vim employs in reading a file)


            rajs
          • Rajendra Sansare
            ... Is it possible to access an unswappable memory location ? ... Supposing you need to keep a document secret, the document being not too big enough, your OS
            Message 5 of 9 , Oct 25, 2002
              On Fri, 25 Oct 2002, Glenn Maynard wrote:

              > You can flag memory as unswappable on any secure OS. GPG probably does
              > this, though probably only for Unix.
              >

              Is it possible to access an unswappable memory location ?


              > If I want a document encrypted, I don't ever want it going to the disk
              > unencrypted. For example, I might encrypt a sensitive document in my
              > home directory to keep it safe from either system compromise (someone
              > gets access to my home directory) or hardware compromise (someone steals
              > my computer). Having a copy lying around in the swapfile defeats this
              > entirely.
              >

              Supposing you need to keep a document secret, the document being not too
              big enough, your OS being Linux/Unix and you create the document, it would
              be safer to encrypt the document at the editing source itself. So dont
              create a swap file in Vim (-n option at startup).

              > Of course, you'd have to be very careful to be sure you only access
              > copies of this data with apps that are smart enough to put it in
              > unswappable memory, including the terminal. It might be a futile task.
              > However, the facilities are there.
              >

              I know of programs which offer crypto facilities, but am unaware of any
              programs that provide encryption/decryption at source.
              Please let me know.

              Thanks

              rajs
            • Glenn Maynard
              ... I don t think it d be very useful otherwise ... ... Referring to VM swap here, not Vim s. ... I m not sure it s possible to decrypt individual blocks
              Message 6 of 9 , Oct 25, 2002
                On Fri, Oct 25, 2002 at 02:41:35PM +0530, Rajendra Sansare wrote:
                > > You can flag memory as unswappable on any secure OS. GPG probably does
                > > this, though probably only for Unix.
                >
                > Is it possible to access an unswappable memory location ?

                I don't think it'd be very useful otherwise ...

                > Supposing you need to keep a document secret, the document being not too
                > big enough, your OS being Linux/Unix and you create the document, it would
                > be safer to encrypt the document at the editing source itself. So dont
                > create a swap file in Vim (-n option at startup).

                Referring to VM swap here, not Vim's.

                > So is there any way in which the file would be read in encrypted form in
                > the buffer, and then a memory location be alotted and small portions of
                > the buffer be decrypted always overwriting the contents of the allocated
                > memory area. (All this without too much of a digress from the current
                > procedure vim employs in reading a file)

                I'm not sure it's possible to decrypt individual "blocks" with GPG; it's
                not meant for random access. (Even if you could convince Vim to do that.)

                --
                Glenn Maynard
              • Tomas Vasko
                ... Yes, you can, but on most unixes you need a root privileges to do so: $man mlock|grep Only root -A1 -B1 EPERM The calling process does not have
                Message 7 of 9 , Oct 25, 2002
                  > > on the disk you have quite a bit of work to do.
                  >
                  > You can flag memory as unswappable on any secure OS. GPG probably does
                  > this, though probably only for Unix.

                  Yes, you can, but on most unixes you need a root privileges to do so:

                  $man mlock|grep 'Only root' -A1 -B1
                  EPERM The calling process does not have appropriate privĀ­
                  ileges. Only root processes are allowed to lock
                  pages.

                  and similary on plock() man page:
                  EPERM The calling process does not have the super-user
                  privilege.

                  thus vim would require a suid bit, what is, I am affraid, unacceptable by
                  most people...

                  --
                  The more I see, The less I believe...
                • Rajendra Sansare
                  ... I understood that you were referring to VM swap, but I wanted to make a point of encrypting at source while taking precaution to leave no swap file (.swp)
                  Message 8 of 9 , Oct 25, 2002
                    On Fri, 25 Oct 2002, Glenn Maynard wrote:

                    > On Fri, Oct 25, 2002 at 02:41:35PM +0530, Rajendra Sansare wrote:
                    > > > You can flag memory as unswappable on any secure OS. GPG probably does
                    > > > this, though probably only for Unix.
                    > >
                    > > Is it possible to access an unswappable memory location ?
                    >
                    > I don't think it'd be very useful otherwise ...
                    >
                    > > Supposing you need to keep a document secret, the document being not too
                    > > big enough, your OS being Linux/Unix and you create the document, it would
                    > > be safer to encrypt the document at the editing source itself. So dont
                    > > create a swap file in Vim (-n option at startup).
                    >
                    > Referring to VM swap here, not Vim's.

                    I understood that you were referring to VM swap, but I wanted to make a
                    point of encrypting at source while taking precaution to leave no swap
                    file (.swp) generated by vim. I mean you could take the precaution
                    to making memory unsewappable but still neglect the swapfile therby
                    leaking the secret.

                    >
                    > I'm not sure it's possible to decrypt individual "blocks" with GPG; it's
                    > not meant for random access. (Even if you could convince Vim to do that.)
                    >

                    Clarification here, I am using GPG only for digital signature, the crypto
                    algo used is "block" cipher Rijndael.

                    So I could immediately follow a decrypt by encrypt before the next block
                    is read.

                    rajs
                  • Wichert Akkerman
                    ... You can lock memory with mlock() for this purpose, but you have to be root to do that (it makes for a nice resource starvation problem if you try to
                    Message 9 of 9 , Nov 2, 2002
                      Previously Glenn Maynard wrote:
                      > You can flag memory as unswappable on any secure OS. GPG probably does
                      > this, though probably only for Unix.

                      You can lock memory with mlock() for this purpose, but you have to be
                      root to do that (it makes for a nice resource starvation problem if you
                      try to mlock() lots of things).

                      Wichert.

                      --
                      _________________________________________________________________
                      /wichert@... This space intentionally left occupied \
                      | wichert@... http://www.wiggy.net/ |
                      | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
                    Your message has been successfully submitted and would be delivered to recipients shortly.