Re: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

2016-06-09 Fir de Conversatie cryptoz
On Thursday, June 9, 2016 at 7:05:58 PM UTC-4, Ben Fritz wrote:
> On Thu, Jun 9, 2016 at 2:56 PM, Charles E Campbell 
>  wrote:
> >  if libraries are used, the system may update the library (while one
> > is on holiday), potentially rendering encrypted text unreadable.  I know
> > that these things should be done in a backwards compatible fashion, but
> > Murphy's Law plus having many users guarantees trouble will happen.
> >
> > I agree that libraries will get better testing, though.
> > 
> 
> Good point. So we should be sure to link statically to the library.
> 
> Of course if the system updates to a new Vim we could still have the problem.
> 
> 
> It sounds like once the encryption is finished we should add a reference 
> version encrypted file to the tests, and test that vim can decrypt it. Then 
> the test will fail if a library update breaks the decryption.

I have read many good points here and would like to share some of my thoughts. 

The focus of Vim should be still on editor. It does not need to repeat all the 
hard work that has been done in other projects (e.g., gpg, openssl). 

The built-in encryption function can be just a few (or just one) good schemes 
using symmetric-key algorithms. People have different opinion/preferences on 
ciphers. My opinion is to take a well studied (and maybe popular) method. For 
example, AES CCMP (or maybe the 256-bit version). 

Another effort is to provide really good support to use 3rd party software so 
people can use whatever software (e.g., gpg, openssl, 7zip, etc.) they like.

Thanks.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: File format issues when using gpg

2016-06-09 Fir de Conversatie cryptoz
On Thursday, June 9, 2016 at 8:20:51 PM UTC-4, James McCoy wrote:
> On Thu, Jun 09, 2016 at 10:19:09AM -0700, cryptoz wrote:
> > I did not more digging and realized that vim has already had a mechanisms to
> > transform input/output streams. I will try BufReadCmd/BufWriteCmd later. 
> 
> 
> You might be interested in my vim-gnupg plugin --
> https://github.com/jamessan/vim-gnupg
> 
> 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Thank you, James. 

I tried the plugin a few years ago and had some issues. 
I mainly use gpg to encrypt files to myself. So I do not need a lot of 
functions. 

I just tried your plugin again. It seems working fine. One issue I noticed is 
windows popping and closing in the background. I will see if I can get used to 
it. 

Thanks again. 

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: File format issues when using gpg

2016-06-09 Fir de Conversatie cryptoz
I did not more digging and realized that vim has already had a mechanisms to
transform input/output streams. I will try BufReadCmd/BufWriteCmd later. 

Thanks.

On Thursday, June 9, 2016 at 9:34:42 AM UTC-4, cryptoz wrote:
> On Thursday, June 9, 2016 at 5:34:10 AM UTC-4, Ken Takata wrote:
> > Hi cryptoz,
> > 
> > 2016/6/9 Thu 15:53:05 UTC+9 cryptoz wrote:
> > > I have followed instructions on the Internet to edit gpg encrypted text 
> > > file transparently. It almost works, but the file format is messed up for 
> > > gpg files. 
> > > 
> > > OS: Windows 10.
> > > vim version: 7.4.1023 and 7.4.1721 (tried both)
> > > 
> > > Problems: 
> > > 
> > > Suppose I have a file a.txt. It has only one character in it (say, 'a'). 
> > > The file has three bytes:
> > > 
> > > : 61 0d 0a
> > > 
> > > If I encrypted the file with gpg without armor, the output file has 
> > > hundreds of binary data. When I opened the gpg file with vim, there is an 
> > > ^M at the end of the line. 
> > > 
> > > The fileformats is set to dos,unix and fileformat (detected) is dos.
> > > 
> > > If I use armored file (.asc), there is no issue.
> > > 
> > > The script I put in _vimrc to open *.gpg,*.asc files is similar to what I
> > > got from http://vim.wikia.com/wiki/Encryption
> > > 
> > > I understand correctly, the steps are:
> > > 
> > > 1. set bin option before read the file.
> > > 2. read the file into buffer.
> > > 3. call gpg to decrypt the buffer. 
> > > 4. set nobin option.
> > > 
> > > I am not sure when fileformat is detected during this process. I tried to 
> > > set fileformat to dos in each step, it did not work. 
> > > 
> > > The problem could be the fileformat detection is done in 2. Since it is a 
> > > binary file, fileformat is set to unix. In step 3, when decrypted text is 
> > > placed back in buffer, there is ^M at the end of each line because 
> > > fileformat
> > > is already set to unix. 
> > > 
> > > I would think a better way to handle similar situations is add a user 
> > > configurable filter to convert the stream read from the file into another 
> > > format (e.g., decryption, encoding) and another filter one for writing.
> > > 
> > > Thanks.
> > 
> > I see a similar problem when I use a setting written in `:help hex-editing`:
> > 
> > augroup Binary
> >   au!
> >   au BufReadPre  *.bin let =1
> >   au BufReadPost *.bin if  | %!xxd
> >   au BufReadPost *.bin set ft=xxd | endif
> >   au BufWritePre *.bin if  | %!xxd -r
> >   au BufWritePre *.bin endif
> >   au BufWritePost *.bin if  | %!xxd
> >   au BufWritePost *.bin set nomod | endif
> > augroup END
> > 
> > When I open a *.bin file on Windows with this setting, each line ends with 
> > ^M.
> > The following setting seems to fix the problem:
> > 
> > augroup Binary
> >   au!
> >   au BufReadPre  *.bin let :bin=1
> >   au BufReadPost *.bin if  | setlocal nobin nofixeol ff=unix | %!xxd
> >   au BufReadPost *.bin setlocal ft=xxd | endif
> >   au BufWritePre *.bin if =="xxd" | setlocal bin | %!xxd -r
> >   au BufWritePre *.bin endif
> >   au BufWritePost *.bin if =="xxd" | setlocal nobin | %!xxd
> >   au BufWritePost *.bin setlocal nomod | endif
> > augroup END
> > 
> > (Sorry, not tested well.)
> > 
> > Maybe we need `set nobin` before reading from a filter and `set bin` before
> > writing to a filter.  'fixeol' and 'ff' should be also adjusted properly.
> > ('fenc' should be also adjusted?)
> > 
> > Regards,
> > Ken Takata
> 
> Thank you, Ken. 
> 
> It seems working in the sense that ^M is removed. 
> 
> I added a line before sending everything to the filter. 
> 
> autocmd BufReadPre,FileReadPre  *.gpg setlocal bin
> autocmd BufReadPost,FileReadPost*.gpg setlocal nobin nofixeol ff=unix
> autocmd BufReadPost,FileReadPost*.gpg,*.asc '[,']!gpg -q --decrypt 2>NUL
> 
> The setlocal nobin line is the newly added one.
> My understanding is that when feeding lines to the filter, try to make it 
> binary (using nofixeol and ff=unix). When reading lines from the filter, 
> treat them as text ( the nobin option). 
> 
> I also think there may be cases this method does not work (or not perfectly). 
> As fileformat is set to unix before using the 

Re: File format issues when using gpg

2016-06-09 Fir de Conversatie cryptoz
On Thursday, June 9, 2016 at 5:34:10 AM UTC-4, Ken Takata wrote:
> Hi cryptoz,
> 
> 2016/6/9 Thu 15:53:05 UTC+9 cryptoz wrote:
> > I have followed instructions on the Internet to edit gpg encrypted text 
> > file transparently. It almost works, but the file format is messed up for 
> > gpg files. 
> > 
> > OS: Windows 10.
> > vim version: 7.4.1023 and 7.4.1721 (tried both)
> > 
> > Problems: 
> > 
> > Suppose I have a file a.txt. It has only one character in it (say, 'a'). 
> > The file has three bytes:
> > 
> > : 61 0d 0a
> > 
> > If I encrypted the file with gpg without armor, the output file has 
> > hundreds of binary data. When I opened the gpg file with vim, there is an 
> > ^M at the end of the line. 
> > 
> > The fileformats is set to dos,unix and fileformat (detected) is dos.
> > 
> > If I use armored file (.asc), there is no issue.
> > 
> > The script I put in _vimrc to open *.gpg,*.asc files is similar to what I
> > got from http://vim.wikia.com/wiki/Encryption
> > 
> > I understand correctly, the steps are:
> > 
> > 1. set bin option before read the file.
> > 2. read the file into buffer.
> > 3. call gpg to decrypt the buffer. 
> > 4. set nobin option.
> > 
> > I am not sure when fileformat is detected during this process. I tried to 
> > set fileformat to dos in each step, it did not work. 
> > 
> > The problem could be the fileformat detection is done in 2. Since it is a 
> > binary file, fileformat is set to unix. In step 3, when decrypted text is 
> > placed back in buffer, there is ^M at the end of each line because 
> > fileformat
> > is already set to unix. 
> > 
> > I would think a better way to handle similar situations is add a user 
> > configurable filter to convert the stream read from the file into another 
> > format (e.g., decryption, encoding) and another filter one for writing.
> > 
> > Thanks.
> 
> I see a similar problem when I use a setting written in `:help hex-editing`:
> 
>   augroup Binary
> au!
> au BufReadPre  *.bin let =1
> au BufReadPost *.bin if  | %!xxd
> au BufReadPost *.bin set ft=xxd | endif
> au BufWritePre *.bin if  | %!xxd -r
> au BufWritePre *.bin endif
> au BufWritePost *.bin if  | %!xxd
> au BufWritePost *.bin set nomod | endif
>   augroup END
> 
> When I open a *.bin file on Windows with this setting, each line ends with ^M.
> The following setting seems to fix the problem:
> 
>   augroup Binary
> au!
> au BufReadPre  *.bin let :bin=1
> au BufReadPost *.bin if  | setlocal nobin nofixeol ff=unix | %!xxd
> au BufReadPost *.bin setlocal ft=xxd | endif
> au BufWritePre *.bin if =="xxd" | setlocal bin | %!xxd -r
> au BufWritePre *.bin endif
> au BufWritePost *.bin if =="xxd" | setlocal nobin | %!xxd
> au BufWritePost *.bin setlocal nomod | endif
>   augroup END
> 
> (Sorry, not tested well.)
> 
> Maybe we need `set nobin` before reading from a filter and `set bin` before
> writing to a filter.  'fixeol' and 'ff' should be also adjusted properly.
> ('fenc' should be also adjusted?)
> 
> Regards,
> Ken Takata

Thank you, Ken. 

It seems working in the sense that ^M is removed. 

I added a line before sending everything to the filter. 

autocmd BufReadPre,FileReadPre  *.gpg setlocal bin
autocmd BufReadPost,FileReadPost*.gpg setlocal nobin nofixeol ff=unix
autocmd BufReadPost,FileReadPost*.gpg,*.asc '[,']!gpg -q --decrypt 2>NUL

The setlocal nobin line is the newly added one.
My understanding is that when feeding lines to the filter, try to make it 
binary (using nofixeol and ff=unix). When reading lines from the filter, treat 
them as text ( the nobin option). 

I also think there may be cases this method does not work (or not perfectly). 
As fileformat is set to unix before using the filter, the output of the filter 
should be unix. This may not be true for the program used in the filter and 
sometimes it is hard to change the behavior.

Another issue is that the fileformat is set to unix manually, the original end 
of line is lost. When saving the file, the end of line is set to unix (when the 
bin option is set before using the output filter).

So I think this method can remove ^M at the end of lines if the end of lines in 
the original file (in my case, the file before encryption) is dos style. When 
saving the file, the end of lines changes to unix style.

A better way to handle this could be a new function in vim: the input and 
output format of the filter can be configured separ

File format issues when using gpg

2016-06-09 Fir de Conversatie cryptoz
I have followed instructions on the Internet to edit gpg encrypted text file 
transparently. It almost works, but the file format is messed up for gpg files. 

OS: Windows 10.
vim version: 7.4.1023 and 7.4.1721 (tried both)

Problems: 

Suppose I have a file a.txt. It has only one character in it (say, 'a'). The 
file has three bytes:

: 61 0d 0a

If I encrypted the file with gpg without armor, the output file has hundreds of 
binary data. When I opened the gpg file with vim, there is an ^M at the end of 
the line. 

The fileformats is set to dos,unix and fileformat (detected) is dos.

If I use armored file (.asc), there is no issue.

The script I put in _vimrc to open *.gpg,*.asc files is similar to what I
got from http://vim.wikia.com/wiki/Encryption

I understand correctly, the steps are:

1. set bin option before read the file.
2. read the file into buffer.
3. call gpg to decrypt the buffer. 
4. set nobin option.

I am not sure when fileformat is detected during this process. I tried to set 
fileformat to dos in each step, it did not work. 

The problem could be the fileformat detection is done in 2. Since it is a 
binary file, fileformat is set to unix. In step 3, when decrypted text is 
placed back in buffer, there is ^M at the end of each line because fileformat
is already set to unix. 

I would think a better way to handle similar situations is add a user 
configurable filter to convert the stream read from the file into another 
format (e.g., decryption, encoding) and another filter one for writing.

Thanks.






-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.