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

[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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Jun 9, 2016 at 2:56 PM, Charles E Campbell <
drc...@campbellfamily.biz> 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.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Charles Campbell]

Bram Moolenaar wrote:
> My favorite example is when I have some text that I don't want my
> neighbor to read. Any encryption that Vim provides works for that.
> Also keep in mind that, no matter how strong your encryption is, there
> is always a weak point. Rembember key loggers? There never ever is
> 100% reliable encryption. So please don't overreact. 
We need quantum cryptography!  :)

Once quantum computers become available, all encryption will be for
nought.  (quantum cryptography, as I understand it, really only tells
you if someone is snooping on a communication intended to be secure; not
really useful for encrypting a file).

Chip Campbell

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Charles E Campbell]

Benjamin Fritz wrote:
>
> On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  > wrote:
> >
> > > Speaking of defaults: I think Vim should default to the strongest
> > > method available. I additionally think Vim should warn on saving with
> > > a known broken format such as the original blowfish implementation, or
> > > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > > compile without the broken algorithms altogether unless the user
> > > specifically passes --include-bad-crypto to the configure script or
> > > something.
> >
> > This has the danger of writing a file on one system, go on holiday and
> > find out you can't open it on your laptop (that actually happened to
> me).
> >
>
> That makes some sense, however it only applies to people who edit the
> same file on multiple systems, AND they don't have the same version of
> Vim on each of those systems.
And, 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.

Chip Campbell

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Bram Moolenaar]

Manuel Ortega wrote:

> On Wed, Mar 23, 2016 at 10:28 PM, Ben Fritz  wrote:
> 
> > On Wednesday, March 23, 2016 at 6:21:21 PM UTC-5, Manuel Ortega wrote:
> > > > That reminds me of something else. Why isn't 'modified' set when you
> > change cryptmethod or the encryption password?
> > >
> > >
> > > Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case
> > the *file* changes, not the buffer.  In the former case neither has
> > changed, so for sure 'modified' should not be set.
> >
> > If you change any of 'fileformat', 'fileencoding', 'bomb', or 'nofixeol'
> > then the buffer doesn't change either, only the file. 'cryptmethod' is the
> > oddball here.
> >
> 
> I knew about the first two, but the last two are *really* surprising.  They
> aren't mentioned at ":help 'mod'", nor are they mentioned at their own
> respective ":help"s.  (Bram, if this is the intended behavior, it should
> probably be documented at least at :h 'mod', and probably :h 'bomb' and :h
> 'fixeol'.)

I'll add a remark.

> > I view the 'modified' flag as saying "if you save this buffer then the
> > file will change".
> 
> If that's what it means, the docs need to be fixed.

No, that's not really what it means.


> > I got caught once while I was testing something where I had the wrong
> > password because I had quit Vim after changing the password, but I hadn't
> > saved yet. Vim let me do that without any complaint, because the buffer
> > wasn't modified.
> 
> Changing 'cryptmethod' should ONLY result in a setting of  if  is
> set to something.  If I haven't turned encryption on, so to speak, then
> setting  to "blowfish2" shouldn't set the modified flag.  (For under
> this circumstance, the file will not change even if the buffer is saved).

Although there is something to say for it, changing this behavior
probably causes more confusion than it solves.  Especially if someone
changes the key then then does "ZZ", expecting the file NOT to be
written.

-- 
hundred-and-one symptoms of being an internet addict:
113. You are asked about a bus schedule, you wonder if it is 16 or 32 bits.

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

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

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 10:47 AM, Manuel Ortega 
wrote:
>
> The purpose of *Vim*'s cryptography, as Bram is trying to stress and
nobody seems to ever internalize, is to keep data secret from neighbors and
family members, i.e., people not sophisticated enough or motivated enough
to e.g., realize that it's VimCrypt, find that webpage, know what a perl
script is, know how to apply it, etc.

I disagree. If that's the case, then why did Vim ever get a new cryptmethod
at all? zip is just fine for those purposes.

>  It is pretty clearly implied in ":h encrypt" that the purpose of Vim's
encryption is not to keep data secret from people who even partly know what
they're doing.
>

I disagree here too. In :help encryption I see "The encrypted text cannot
be read without the right key" and "You could do this to edit very secret
text." In :help 'cryptmethod' I see blowfish and blowfish2 described as
"medium strong encryption." Nowhere do I get the impression Vim's
cryptography is not secure enough to keep data secret from people who know
what you're doing. In fact I get the opposite impression, that Vim's
cryptography is probably strong enough for most purposes if you use
"blowfish2".

> For this purpose, it works.
>
> But really: it shouldn't be Vim's job to encrypt files on disk anymore
than it's Vim's job to do compression and decompression.  There are plugins
to use GPG transparently like there are for compressing and decompressing
transparently.
>

And I disagree yet again here. If encryption is not built into the editor,
then you cannot use features like swap files or undo files or you risk
exposing decrypted text in those files. I think it's a great feature to
support encryption in the editor itself to avoid exposing data like that.
Additionally the editor could lock the memory to prevent unencrypted data
in a buffer from getting saved off to swap space. I don't know whether Vim
does that (it probably should), but there's no way you could do that
outside of Vim. So either you need some sort of editor built into your
encryption program with fewer features than Vim, or you need to do the
encryption within Vim, or Vim needs to provide better hooks for external
tools to encrypt in multiple places.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 9:54 AM, Benjamin Fritz 
wrote:
>
> The help entry blowfish and blowfish2 both say "medium strong
encryption". An "implementation flaw" is mentioned for blowfish, but IIUC
the flaw is severe enough to make it much, much weaker than blowfish2. Why
are they both summarized as the same strength?
>

Ah, I see some stronger warnings in :help encrypt. I think those should be
emphasized more and maybe cross-referenced in the help for 'cryptmethod'.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Manuel Ortega]

On Thu, Mar 24, 2016 at 10:54 AM, Benjamin Fritz 
wrote:

>
>
> On Thu, Mar 24, 2016 at 6:08 AM, Bram Moolenaar 
> wrote:
> >
> >
> > Ben Fritz wrote:
> >
> > > On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar 
> wrote:
> > > > The original blowfish encryption is not broken, it's just weaker
> than it
> > > > should be.  It's still a lot stronger than zip.
> > >
> > > Is it? This page makes it sound like "blowfish" was pretty much
> completely
> > > broken if you knew any of the plaintext:
> https://dgl.cx/2014/10/vim-blowfish
> >
> > Your definition of broken is wrong.  Broken means it doesn't work at
> > all.  e.g., Vim crashes when using it, or when decrypting you can't get
> > back the original text.  When do you call a car broken?  When you can't
> > drive.  Not when you can't open the window.
> >
>
> I call something "broken" when it cannot serve its intended purpose.
> Cryptography's purpose is to keep data secret.
>

The purpose of *Vim*'s cryptography, as Bram is trying to stress and nobody
seems to ever internalize, is to keep data secret from neighbors and family
members, i.e., people not sophisticated enough or motivated enough to e.g.,
realize that it's VimCrypt, find that webpage, know what a perl script is,
know how to apply it, etc.  It is pretty clearly implied in ":h encrypt"
that the purpose of Vim's encryption is not to keep data secret from people
who even partly know what they're doing.

For this purpose, it works.

But really: it shouldn't be Vim's job to encrypt files on disk anymore than
it's Vim's job to do compression and decompression.  There are plugins to
use GPG transparently like there are for compressing and decompressing
transparently.

-Manny

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Thu, Mar 24, 2016 at 6:08 AM, Bram Moolenaar  wrote:
>
>
> Ben Fritz wrote:
>
> > On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar 
wrote:
> > > The original blowfish encryption is not broken, it's just weaker than
it
> > > should be.  It's still a lot stronger than zip.
> >
> > Is it? This page makes it sound like "blowfish" was pretty much
completely
> > broken if you knew any of the plaintext:
https://dgl.cx/2014/10/vim-blowfish
>
> Your definition of broken is wrong.  Broken means it doesn't work at
> all.  e.g., Vim crashes when using it, or when decrypting you can't get
> back the original text.  When do you call a car broken?  When you can't
> drive.  Not when you can't open the window.
>

I call something "broken" when it cannot serve its intended purpose.
Cryptography's purpose is to keep data secret. If that article is correct,
then with "blowfish" (not "blowfish2") there is a trivial attack that can
expose *at least* 64 characters of text in a file without ever knowing the
password. I'm not clear on the details (the article hand-waves a bit) but
potentially the rest of the file may also be recoverable.

If the encrypted file is the basis of a [password manager](
http://www.vim.org/scripts/script.php?script_id=5340) for example, then
this is quite bad. At least the first password is probably compromised if
an attacker gains access to the file.

If anything, this makes "blowfish" *worse* than zip in many scenarios. At
least with zip the attacker needs to work for it.

> > For example, if you had plugin that always writes a predictable header
text
> > to an encrypted file before the actual sensitive data, the attacker
would
> > know some plaintext. I'm certainly not comfortable using "blowfish",
> > knowing it had exploitable flaws fixed in blowfish2. I thought
"blowfish"
> > was just around to let people read their old data (and hopefully
convert to
> > blowfish2).
> >
> > And while I can probably *personally* use a strong-enough passphrase to
let
> > the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it
to
> > anyone else, since I know most people choose passwords that can fall way
> > too fast with modern tools and techniques. I'd consider "blowfish2" to
be
> > broken for *general use* as well since you need a REALLY good password
for
> > it to provide any long-term security guarantees. Once we increase the
KDF
> > iterations sufficiently I would warn when saving in blowfish2 as well,
in
> > favor of the new method(s) using a better KDF.
>
> My favorite example is when I have some text that I don't want my
> neighbor to read.  Any encryption that Vim provides works for that.
>

That's a straw-man argument. You could also do ggg?G to rot13 the buffer
which would keep my neighbor or my kids from reading the file. If that's
not enough then a simple plugin to do a Caesar cipher as a
BufWritePre/BufRead would also do the trick. But nobody would seriously
suggest either of those are secure. Encryption must have a higher standard
than keeping out your non-hacker friends.

The help entry blowfish and blowfish2 both say "medium strong encryption".
An "implementation flaw" is mentioned for blowfish, but IIUC the flaw is
severe enough to make it much, much weaker than blowfish2. Why are they
both summarized as the same strength?

> Also keep in mind that, no matter how strong your encryption is, there
> is always a weak point.  Rembember key loggers?  There never ever is
> 100% reliable encryption.
>
> So please don't overreact.
>

This is true. Neither Vim nor any other encryption tool will protect from a
compromised system. I don't expect Vim to keep me safe from everything. But
I do expect, if I encrypt a file with any modern crypto tool, that I don't
need to worry if that file is snagged off my cloud storage, or someone
steals my USB stick, or something. Representing a crypto implementation as
"secure" when it is trivial to recover some number of bytes in a file is
going to leak someone's sensitive data because they trusted you. I don't
think it's overreacting to say "we shouldn't present weak crypto as strong
enough to keep using".

Maybe "broken" is too changed a word, I'll stop using it. I'll put it this
way:

zip - insecure, all of your file can be recovered with commonly available
tools. Not recommended.
blowfish - insecure, part or all of your file can be recovered with known
methods. Not recommended.
blowfish2 - secure for small files if you use a very strong password and
nobody else has write access.
proposed new methods - secure if you don't use a very weak password like
"123456", "password", or "letmein".

-- 
-- 
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 

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

[Bram Moolenaar]

Ben Fritz wrote:

> On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  wrote:
> >
> > > Speaking of defaults: I think Vim should default to the strongest
> > > method available. I additionally think Vim should warn on saving with
> > > a known broken format such as the original blowfish implementation, or
> > > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > > compile without the broken algorithms altogether unless the user
> > > specifically passes --include-bad-crypto to the configure script or
> > > something.
> >
> > This has the danger of writing a file on one system, go on holiday and
> > find out you can't open it on your laptop (that actually happened to me).
> >
> 
> That makes some sense, however it only applies to people who edit the same
> file on multiple systems, AND they don't have the same version of Vim on
> each of those systems.
> 
> If you don't need that capability, having the old broken systems still in
> the code makes it too easy to make a mistake that could compromise your
> security.
> 
> DROWN recently showed some of the problems with keeping older known-broken
> crypto code enabled by default. I think it makes sense to keep the code
> there for people who deliberately choose to use it. But getting rid of it
> by default can potentially remove an attack vector.
> 
> At the very least, we should warn when saving in an insecure format.
> 
> > I think there should be some number of months between making a new
> > method available and making it the default.
> >
> 
> OK, that's fair.
> 
> > The original blowfish encryption is not broken, it's just weaker than it
> > should be.  It's still a lot stronger than zip.
> 
> Is it? This page makes it sound like "blowfish" was pretty much completely
> broken if you knew any of the plaintext: https://dgl.cx/2014/10/vim-blowfish

Your definition of broken is wrong.  Broken means it doesn't work at
all.  e.g., Vim crashes when using it, or when decrypting you can't get
back the original text.  When do you call a car broken?  When you can't
drive.  Not when you can't open the window.

> For example, if you had plugin that always writes a predictable header text
> to an encrypted file before the actual sensitive data, the attacker would
> know some plaintext. I'm certainly not comfortable using "blowfish",
> knowing it had exploitable flaws fixed in blowfish2. I thought "blowfish"
> was just around to let people read their old data (and hopefully convert to
> blowfish2).
> 
> And while I can probably *personally* use a strong-enough passphrase to let
> the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it to
> anyone else, since I know most people choose passwords that can fall way
> too fast with modern tools and techniques. I'd consider "blowfish2" to be
> broken for *general use* as well since you need a REALLY good password for
> it to provide any long-term security guarantees. Once we increase the KDF
> iterations sufficiently I would warn when saving in blowfish2 as well, in
> favor of the new method(s) using a better KDF.

My favorite example is when I have some text that I don't want my
neighbor to read.  Any encryption that Vim provides works for that.

Also keep in mind that, no matter how strong your encryption is, there
is always a weak point.  Rembember key loggers?  There never ever is
100% reliable encryption.

So please don't overreact.

-- 
hundred-and-one symptoms of being an internet addict:
107. When using your phone you forget that you don't have to use your
 keyboard.

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

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

[Manuel Ortega]

On Wed, Mar 23, 2016 at 10:28 PM, Ben Fritz  wrote:

> On Wednesday, March 23, 2016 at 6:21:21 PM UTC-5, Manuel Ortega wrote:
> > > That reminds me of something else. Why isn't 'modified' set when you
> change cryptmethod or the encryption password?
> >
> >
> > Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case
> the *file* changes, not the buffer.  In the former case neither has
> changed, so for sure 'modified' should not be set.
> >
> >
>
> If you change any of 'fileformat', 'fileencoding', 'bomb', or 'nofixeol'
> then the buffer doesn't change either, only the file. 'cryptmethod' is the
> oddball here.
>

I knew about the first two, but the last two are *really* surprising.  They
aren't mentioned at ":help 'mod'", nor are they mentioned at their own
respective ":help"s.  (Bram, if this is the intended behavior, it should
probably be documented at least at :h 'mod', and probably :h 'bomb' and :h
'fixeol'.)


> I view the 'modified' flag as saying "if you save this buffer then the
> file will change".
>

If that's what it means, the docs need to be fixed.


> I got caught once while I was testing something where I had the wrong
> password because I had quit Vim after changing the password, but I hadn't
> saved yet. Vim let me do that without any complaint, because the buffer
> wasn't modified.
>

Changing 'cryptmethod' should ONLY result in a setting of  if  is
set to something.  If I haven't turned encryption on, so to speak, then
setting  to "blowfish2" shouldn't set the modified flag.  (For under
this circumstance, the file will not change even if the buffer is saved).

-Manny

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Ben Fritz]

On Wednesday, March 23, 2016 at 6:21:21 PM UTC-5, Manuel Ortega wrote:
> > That reminds me of something else. Why isn't 'modified' set when you change 
> >cryptmethod or the encryption password?
> 
> 
> 
> 
> 
> Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case the 
> *file* changes, not the buffer.  In the former case neither has changed, so 
> for sure 'modified' should not be set.
> 
> 

If you change any of 'fileformat', 'fileencoding', 'bomb', or 'nofixeol' then 
the buffer doesn't change either, only the file. 'cryptmethod' is the oddball 
here.

I view the 'modified' flag as saying "if you save this buffer then the file 
will change".

I got caught once while I was testing something where I had the wrong password 
because I had quit Vim after changing the password, but I hadn't saved yet. Vim 
let me do that without any complaint, because the buffer wasn't modified.

This might be a decent use for an OptionSet autocmd event, but that seems like 
a hack.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Manuel Ortega]

> That reminds me of something else. Why isn't 'modified' set when you
change cryptmethod or the encryption password?

>
Isn't it because the *buffer* hasn't changed?  IIUC, in the latter case the
*file* changes, not the buffer.  In the former case neither has changed, so
for sure 'modified' should not be set.

-Manny

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Wed, Mar 23, 2016 at 5:51 PM, Benjamin Fritz 
wrote:
>
> I thought "blowfish" was just around to let people read their old data
(and hopefully convert to blowfish2).

That reminds me of something else. Why isn't 'modified' set when you change
cryptmethod or the encryption password?

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Benjamin Fritz]

On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  wrote:
>
> > Speaking of defaults: I think Vim should default to the strongest
> > method available. I additionally think Vim should warn on saving with
> > a known broken format such as the original blowfish implementation, or
> > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > compile without the broken algorithms altogether unless the user
> > specifically passes --include-bad-crypto to the configure script or
> > something.
>
> This has the danger of writing a file on one system, go on holiday and
> find out you can't open it on your laptop (that actually happened to me).
>

That makes some sense, however it only applies to people who edit the same
file on multiple systems, AND they don't have the same version of Vim on
each of those systems.

If you don't need that capability, having the old broken systems still in
the code makes it too easy to make a mistake that could compromise your
security.

DROWN recently showed some of the problems with keeping older known-broken
crypto code enabled by default. I think it makes sense to keep the code
there for people who deliberately choose to use it. But getting rid of it
by default can potentially remove an attack vector.

At the very least, we should warn when saving in an insecure format.

> I think there should be some number of months between making a new
> method available and making it the default.
>

OK, that's fair.

> The original blowfish encryption is not broken, it's just weaker than it
> should be.  It's still a lot stronger than zip.

Is it? This page makes it sound like "blowfish" was pretty much completely
broken if you knew any of the plaintext: https://dgl.cx/2014/10/vim-blowfish

For example, if you had plugin that always writes a predictable header text
to an encrypted file before the actual sensitive data, the attacker would
know some plaintext. I'm certainly not comfortable using "blowfish",
knowing it had exploitable flaws fixed in blowfish2. I thought "blowfish"
was just around to let people read their old data (and hopefully convert to
blowfish2).

And while I can probably *personally* use a strong-enough passphrase to let
the current too-fast KDF for blowfish2 suffice, I wouldn't recommend it to
anyone else, since I know most people choose passwords that can fall way
too fast with modern tools and techniques. I'd consider "blowfish2" to be
broken for *general use* as well since you need a REALLY good password for
it to provide any long-term security guarantees. Once we increase the KDF
iterations sufficiently I would warn when saving in blowfish2 as well, in
favor of the new method(s) using a better KDF.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Bram Moolenaar]

Ben Fritz wrote:

> On Saturday, March 19, 2016 at 1:43:30 PM UTC-5, Demetri Obenour wrote:
> > Argon2 is implemented in libsodium and is the winner of the Password 
> > Hashing Competition.  It is designed as a KDF.
> > 
> > 
> > However, note that the rest of Vim's cryptmethod is also poorly 
> > implemented.  My suggestion is to use Argon2 as a KDF and either 
> > XSalsa20-Poly1305 or XChaCha20-Poly1305 (with a strong, random nonce) for 
> > authenticated encryption.
> > 
> > 
> > libsodium provides high-level APIs for password hashing and authenticated 
> > encryption and is my strong suggestion.
> > 
> > 
> 
> My thoughts on this are:
> 
> It's best to use a library. With a library we're going to get any
> security updates from people who presumably know what they're doing
> and spend time learning about exploits so they can address them in
> their code. Also researchers are actually likely to test an external
> library, but not Vim's internal code.

libsodium is currently at version 1.0.8. The version included with
Ubuntu is 1.0.3 ...

> However it's useful to have *something* available on every system Vim
> supports, so I think something should be baked in, still. Also Vim
> needs to be able to read old files.

We could use configure to find a library and when it's not available or
older fall back to the built-in code.

> Speaking of defaults: I think Vim should default to the strongest
> method available. I additionally think Vim should warn on saving with
> a known broken format such as the original blowfish implementation, or
> the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> compile without the broken algorithms altogether unless the user
> specifically passes --include-bad-crypto to the configure script or
> something.

This has the danger of writing a file on one system, go on holiday and
find out you can't open it on your laptop (that actually happened to me).

I think there should be some number of months between making a new
method available and making it the default.

The original blowfish encryption is not broken, it's just weaker than it
should be.  It's still a lot stronger than zip.

> Bram, are you already working on any of this? I have been thinking
> about starting an implementation of some of the above but that's a lot
> of work I don't want going to waste if you have other ideas. Maybe
> hashing out a top-level interface and goals, then making a fork for
> more distributed development, would be a decent idea? I don't think
> any halfway implementations will be useful, especially since we'll
> probably need to grow a blowfish3 or other cryptmethod to use the new
> KDF (preferably in a forwards-compatible way to handle other new KDFs
> that may come along in the future).

No, several people have given their opinion but nobody has done actual
work...

-- 
Laughing helps. It's like jogging on the inside.

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

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

[Ben Fritz]

On Monday, March 21, 2016 at 11:04:15 AM UTC-5, Scott wrote:
> (Slight nit: it's PBKDF2. The acronym stands for "Password-Based Key 
> Derivation Function #2".)
> 
> 

Thanks, I knew that, I just was typing faster than I was thinking apparently. 
That's one of those acronyms I really need to expand out in my head before 
typing correctly. I do the same thing with IMDB which occasionally lands me on 
some interesting cyber-squatter pages. :-(

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Ben Fritz]

On Monday, March 21, 2016 at 11:00:31 AM UTC-5, Ben Fritz wrote:
> On Saturday, March 19, 2016 at 1:43:30 PM UTC-5, Demetri Obenour wrote:
> > Argon2 is implemented in libsodium and is the winner of the Password 
> > Hashing Competition.  It is designed as a KDF.
> > 
> > 
> > However, note that the rest of Vim's cryptmethod is also poorly 
> > implemented.  My suggestion is to use Argon2 as a KDF and either 
> > XSalsa20-Poly1305 or XChaCha20-Poly1305 (with a strong, random nonce) for 
> > authenticated encryption.
> > 
> > 
> > libsodium provides high-level APIs for password hashing and authenticated 
> > encryption and is my strong suggestion.
> > 
> > 
> 
> My thoughts on this are:
> 

Oh, and I forgot one more:

While there *may* not be any exploitable weakness related to non-authenticated 
encryption *in Vim's case*, we can't prove it. And, if such an attack exists, 
Vim *will* be vulnerable. If we're already modifying the crypto code (and we 
should, because the KDF is way too weak) then we may as well throw in a MAC to 
prevent the *possibility* of a chosen-ciphertext attack. It shouldn't harm 
anything and it could potentially help a lot. I say we re-open the issue that 
got created for non-authenticated encryption.

-- 
-- 
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: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Ben Fritz]

On Saturday, March 19, 2016 at 1:43:30 PM UTC-5, Demetri Obenour wrote:
> Argon2 is implemented in libsodium and is the winner of the Password Hashing 
> Competition.  It is designed as a KDF.
> 
> 
> However, note that the rest of Vim's cryptmethod is also poorly implemented.  
> My suggestion is to use Argon2 as a KDF and either XSalsa20-Poly1305 or 
> XChaCha20-Poly1305 (with a strong, random nonce) for authenticated encryption.
> 
> 
> libsodium provides high-level APIs for password hashing and authenticated 
> encryption and is my strong suggestion.
> 
> 

My thoughts on this are:

It's best to use a library. With a library we're going to get any security 
updates from people who presumably know what they're doing and spend time 
learning about exploits so they can address them in their code. Also 
researchers are actually likely to test an external library, but not Vim's 
internal code.

However it's useful to have *something* available on every system Vim supports, 
so I think something should be baked in, still. Also Vim needs to be able to 
read old files.

I think adding a 'cryptkdf' option would be a decent idea. Include something 
built-in; either copied from a library with a license that allows it (probably 
best), or something simple like PDKDF2 (we already have a SHA256 we could use a 
a building block). But also include an option for a library implementation of a 
few algorithms. Argon2 is a good idea but it's still pretty new so if a flaw is 
found another method would probably be nice to have already available, so maybe 
the choices could be something like 'pdkdf2', 'lib-scrypt', and 'lib-argon2' 
for starters.

The number of iterations is key for the security of these algorithms. I'm 
vaguely aware that scrypt and argon2 are also configurable in memory use, but I 
know a lot less about that. But regardless we'll want to allow configuring the 
KDF to scale with hardware without recompiling Vim. So a 'cryptkdfcount' or 
similar option should also be provided. I think a good way to do this would be 
to allow both numeric values, but also time values. For example, the user could 
do ":set cryptkdfcount=1s" and Vim would estimate how many iterations would 
take a full second on the current hardware and use that. 1-3 seconds is 
probably a reasonable default value as well.

Speaking of defaults: I think Vim should default to the strongest method 
available. I additionally think Vim should warn on saving with a known broken 
format such as the original blowfish implementation, or the zip algorithm, or 
even blowfish2 without a decent KDF. Maybe even compile without the broken 
algorithms altogether unless the user specifically passes --include-bad-crypto 
to the configure script or something.

As for blowfish: I'm not very concerned about the weaknesses in the algorithm 
*for the specific uses Vim is likely to use it for*, however having a better 
encryption algorithm available is much nicer. Nevertheless, I *am* a little 
concerned whether we know the algorithm is implemented properly. I'd like to 
see output from Vim's implementation matched up against output from a 
well-known library implementation. In theory with the same salt, same IV, and 
same key, I think they should be compatible.

I should note here that I'm also a little uneasy with the current salt/IV 
generation. Basically it's just one system time (in microseconds) and a hash (I 
doubt the rand() adds anything useful). That could be a lot better, using 
/dev/urandom for example where supported, or the equivalent. Or maybe hash 
system time (still in microseconds) with a previous hash periodically, say 
while waiting for user input or something; I'm not familiar with best practices 
when a good system-provided random source is missing. I say I'm "uneasy" 
because I doubt there's any good exploit for this in Vim's use scenarios, but 
it's documented widely that a good unpredictable IV is required for CBC mode 
encryption, so I don't get any warm fuzzies from the "random" code here.

Bram, are you already working on any of this? I have been thinking about 
starting an implementation of some of the above but that's a lot of work I 
don't want going to waste if you have other ideas. Maybe hashing out a 
top-level interface and goals, then making a fork for more distributed 
development, would be a decent idea? I don't think any halfway implementations 
will be useful, especially since we'll probably need to grow a blowfish3 or 
other cryptmethod to use the new KDF (preferably in a forwards-compatible way 
to handle other new KDFs that may come along in the future).

-- 
-- 
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