Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vim cryptmethod is not authenticated #638

Closed
atoponce opened this issue Feb 16, 2016 · 64 comments

Comments

Projects
None yet
@atoponce
Copy link

commented Feb 16, 2016

When using cryptmethod=blowfish2, the saved ciphertext is not authenticated with a message authentication code ("MAC tag"). Consider saving "Lorem ipsum dolor sit amet, consectetur adipiscing elit." to a text file, and getting the SHA-256 digest of the ciphertext:

$ vim -x /tmp/lorem.txt
(Use "vim" as the passphrase)
$ sha256sum /tmp/lorem.txt
510e57357353d511dac719bc238900456332ca0e4c00bcf12d244fdc66355f8e  /tmp/lorem.txt

Now deliberately corrupt the file:

$ dd seek=50 conv=notrunc bs=1 count=10 if=/dev/urandom of=/tmp/lorem.txt
10+0 records in
10+0 records out
10 bytes copied, 0.000293754 s, 34.0 kB/s

Notice the SHA-256 digest has changed. Open the file, and notice that the plaintext has changed:

$ sha256sum /tmp/lorem.txt 
f17d3494643ed8bef5f0ba7fd67af6682f0332a0bccf52e9a2640604bec0b111  /tmp/lorem.txt
$ vim -x /tmp/lorem.txt
(Use "vim" as the passphrase)

I get "Lorem ipsum dolor sit £ÕH<8a>`7^T¸³­#÷f;Qüצadipiscing elit." returned. Your mileage may vary.

If the ciphertext was authenticated with a cryptographically secure hashing function (Skein by Bruce Schneier would be fitting, given the use of his Blowfish algorithm as the symmetric cipher), and if the MAC tag was calculated on the ciphertext, then when attempting to decrypt, if the MAC tag did not match the newly calculated MAC tag, Vim should error out, rather than decrypting and displaying the file. See the Wikipedia article on "Encrypt-then-MAC".

Vim should use "Encrypt-then-MAC" authenticated encryption when using cryptmethod.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 16, 2016

I brought up a similar issue with neovim, suggesting crypto be removed: neovim/neovim#694 (and they did indeed remove it)

Using malleable, unauthenticated cryptography exposes you to a whole class of attacks which modern authenticated ciphers prevent. You should really use the latter.

As to the threat model and specific attacks, we can try to talk about that, but really most excuses I've seen people make about failing to move to modern, authenticated ciphers have only lead to additional attacks. See also @moxie0's The Cryptographic Doom Principle:

http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 16, 2016

Looks like you're including sha256.c for sha256_key() with the password rotation. You could use HMAC-SHA256 instead for your MAC, so you won't need to bring in any additional code.

However, instead of key derivation using SHA-256, you should look at using bcrypt. I'll create a separate issue for this. See #639.

@brammool

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2016

Aaron Toponce wrote:

When using cryptmethod=blowfish2, the saved ciphertext is not
authenticated with a message authentication code ("MAC tag"). Consider
saving "Lorem ipsum dolor sit amet, consectetur adipiscing elit." to a
text file, and getting the SHA-256 digest of the ciphertext:

$ vim -x /tmp/lorem.txt
(Use "vim" as the passphrase)
$ sha256sum /tmp/lorem.txt
510e57357353d511dac719bc238900456332ca0e4c00bcf12d244fdc66355f8e  /tmp/lorem.txt

Now deliberately corrupt the file:

$ dd seek=50 conv=notrunc bs=1 count=10 if=/dev/urandom of=/tmp/lorem.txt
10+0 records in
10+0 records out
10 bytes copied, 0.000293754 s, 34.0 kB/s

Notice the SHA-256 digest has changed. Open the file, and notice that
the plaintext has changed:

$ sha256sum /tmp/lorem.txt 
f17d3494643ed8bef5f0ba7fd67af6682f0332a0bccf52e9a2640604bec0b111  /tmp/lorem.txt
$ vim -x /tmp/lorem.txt
(Use "vim" as the passphrase)

I get "Lorem ipsum dolor sit £ÕH<8a>`7^T¸³­#÷f;Qüצadipiscing elit."
returned. Your mileage may vary.

So? The encryption is meant to avoid other people, who don't have the
key, from reading the text. It does not have the goal of protecting
manipulation of the text, that is something else. You could add a
checksum even when not using encryption. I believe it's called signing.

Adding a checksum actually makes breaking the encryption easier. I don't
know by how much, it depends on a way to check if the decription seemed
to have worked. That can be avoided by performing another operation
first, e.g. compressing the text.

If the ciphertext was authenticated with a cryptographically secure
hashing function
(Skein by
Bruce Schneier would be fitting, given the use of his Blowfish
algorithm as the symmetric cipher), and if the MAC tag was calculated
on the ciphertext, then when attempting to decrypt, if the MAC tag did
not match the newly calculated MAC tag, Vim should error out, rather
than decrypting and displaying the file. See the Wikipedia article on
"Encrypt-then-MAC".

Vim should use "Encrypt-then-MAC" authenticated encryption when using
cryptmethod.

It's possible to add this as a new crypt method, for those people who
need to protect their text from being changed by others.

This is an airconditioned room, do not open Windows.

/// Bram Moolenaar -- Bram@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 ///

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 16, 2016

So? The encryption is meant to avoid other people, who don't have the key, from reading the text. It does not have the goal of protecting manipulation of the text, that is something else. You could add a checksum even when not using encryption. I believe it's called signing.

There are some subtle differences between checksums, digital signatures, and message authentication codes:

Checksums only provide anonymous data integrity. The problem with blind checksums in ciphertext, is anyone can replace the checksum after replacing or modifying the ciphertext.

Digital signtaures are usually associated with public key cryptography, and imply a physical personality. IE: John Doe signed this data with his private key. Digital signatures provide data integrity attached to personal identity, and provide non-repudiation.

Message authentication codes (MAC tags) are similar to digital signatures, but used with symmetric cryptography. They are anonymous "digital signatures", in that they provide data integrity, while also providing authentication via the use of a secret key only selected privileged parties have access to. No personal identity is attached to the MAC.

The goal with this issue, is to provide authenticated encryption to the ciphertext, so not only is data integrity maintained, but also prevents external modification without knowledge of the authentication key to produce a new MAC. So, not only do we get data privacy with Blowfish, but we get authentication with HMAC-SHA256.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 16, 2016

However, instead of key derivation using SHA-256, you should look at using bcrypt.

bcrypt is not intended to be used as a KDF (unlike PBKDF2 or scrypt)

Issues like this are why rolling your own crypto is a bad idea.

I would suggest removing all of the existing homebrew crypto code (as neovim did) and adding first class support for a tool like GPG for doing encryption.

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 16, 2016

bcrypt is not intended to be used as a KDF (unlike PBKDF2 or scrypt)

Indeed. That was a bad recommendation (this crypto stuff is full of sharp edges- who knew? :) )

I would suggest removing all of the existing homebrew crypto code (as neovim did) and adding first class support for a tool like GPG for doing encryption.

I fully support this also. "-x" is nice for those who don't want to manage their own keys. But, as shown in this ticket and #639, it's weak and falls victim to all sorts of problems, and fixing it isn't exactly "easy".

@chrisbra

This comment has been minimized.

Copy link
Member

commented Feb 16, 2016

@tarcieri

This comment has been minimized.

Copy link

commented Feb 16, 2016

What problem does that fix?

It would fix both the issues with weak key derivation (which could allow passwords to be brute forced) and malleable ciphertexts.

GPG, despite its warts, has after a great deal of time generally managed to get the crypto right.

And how are users supposed to open existing encrypted files then?

The existing crypto could be left in in a read-only capacity for a bit to allow recovery of old encrypted files, but ideally it'd be removed altogether (as neovim did)

@vim-ml

This comment has been minimized.

Copy link

commented Feb 19, 2016

On Monday, February 15, 2016 at 10:19:46 PM UTC-6, Tony Arcieri wrote:

I brought up a similar issue with neovim, suggesting crypto be removed: neovim/neovim#694

Using malleable, unauthenticated cryptography exposes you to a whole class of attacks which modern authenticated ciphers prevent. You should really use the latter.

In communication over an untrusted network, sure. Absolutely.

But what sorts of attacks does this leave you vulnerable for local storage on one computer where the "receiver" of the data is the same person as the "sender"? This isn't Alice, Bob, and Eve. This is Alice trying to protect a file from someone who comes along afterward and can't manipulate or learn about any of the encryption in real time.

If you're worried about someone being able to write files on the machine, then what about a script that creates a file in ~/.vim/plugin, which will install an autocmd to dump a plaintext copy of a buffer any time it sees that encryption is enabled after reading the file? That would be a much easier attack with much higher chances of success, and probably less chance of detection.

Or just get access to the memory of the Vim process somehow, since apparently you can run arbitrary processes on the system.

As Bram points out, Vim's encryption isn't trying to protect the integrity of data. Only its secrecy.

If I'm missing an attack vector here that compromises the ability to keep the plaintext secret, please enlighten me, and I'd be more than happy to see Vim's encryption go (or get fixed).

As to the threat model and specific attacks, we can try to talk about that, but really most excuses I've seen people make about failing to move to modern, authenticated ciphers have only lead to additional attacks. See also @moxie0's The Cryptographic Doom Principle:

http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/

This article seems to talk entirely about point-to-point protocols with an eavesdropper (with active attacks even, not just passive listening). That's nothing like what Vim is doing. And the attacks listed there rely on the MAC, which as you point out, Vim omits anyway. AND they are timing attacks, which if you have the capability to carry out on Vim's encryption, you could do much easier and more effective attacks anyway as I point out above.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

@vim-ml (not sure exactly sure who I'm talking to, but hi there some random person on the mailing list!)

Ok, let's talk about threat models.

The set of threat models where confidentiality matters but integrity does not is vanishingly small.

But what sorts of attacks does this leave you vulnerable for local storage on one computer where the "receiver" of the data is the same person as the "sender"?

If there's only one party, we don't need encryption at all! If we have a computer that only one person ever interacts with ever (i.e. a non-networked, airgapped computer stored in a secure physical location), then there's no threat. If you believe the integrity of the file does not matter, that's because you're assuming one of the following:

  1. There is no attacker
  2. There is an attacker who has read-only access to the file but is unable to manipulate it

The former is irrelevant to me: if there are no attackers we don't need cryptography... problem solved! In the case of the latter, you're assuming there is an attacker but are relying on OS-level protections to preserve the integrity of the file.

However, if we assume the OS can preserve the integrity of the file, why not the confidentiality? Just set the appropriate POSIX file permissions, and again, we don't need cryptography: the OS is preserving the confidentiality of the file for us. Just don't make the file world readable or accessible by any user or group the attacker may possibly belong to. Problem solved!

There is pretty much one threat model (ok, two if we count LFD) under which confidentiality is important and integrity is not: full disk encryption. In this threat model, I lose my device. I never get it back. An attacker now has physical access to the device, but not the credentials to unlock it. We want to prevent the attacker from accessing data on the device.

If that's the threat: use full-disk encryption. It's implemented by people who know what they're doing. It covers all files on the device, not just any given particular one. It also lets you unlock the entire device with the same credential you use to log in, as opposed to a separate credential per file.

So the question is: in what use cases is vim encryption actually helpful? There are things like local file disclosure attacks / "directory traversal" which a confidentiality-only mechanism can help you in. But this is where we get to what I'll call the "lead paint" analogy.

Once in a simpler, more naive time, they put lead in paint. Turns out lead is toxic, and we can make paint without lead.

Should we switch? Switching is hard. Can't we just tell people not to eat the paint chips and to take proper care to use gloves and not come in physical contact with the paint when painting, and not to lick the walls?

We can put big warnings on the product not to do this! But people are still going to eat the paint chips anyway. If they get sick, whose fault is it?

You can try to educate people about the hyperspecific threat model unauthenticated, malleable, "obsolete" cryptography which protects only confidentiality but not integrity prevents. "WARNING: only helpful against local file disclosure attacks!" If people don't pay attention to these warnings, it's their own damn fault, right? Just blame the cryptographic user if any problems occur.

Or you can get rid of the lead, and switch to modern authenticated encryption modes, and protect from a much broader range of threats.

Here is the state of vim's encryption:

  1. It's not just using malleable, unauthenticated cryptography which is bad because of the very limited number of threats it protects against...
  2. It's using a weak password-based key derivation algorithm which is vulnerable to brute force attacks
  3. It's using a cipher (Blowfish) whose creator does not recommend using it anymore: "At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead." -- Bruce Schneier
  4. It's using a cipher with a small block size (64-bits)
  5. It's using a cipher vulnerable to reflectively weak key attacks
  6. It's using an on-disk format which is incompatible with anything except vim

This is bad cryptography. Your argument is the user should understand the very limited set of threats it protects against. They probably don't. Someone is going to eat those lead paint chips.

There are better options available. We have the technology.

Why do you think it's a good idea to keep shipping non-interoperable, obsolete crypto full of sharp edges?

@paragonie-scott

This comment has been minimized.

Copy link

commented Feb 19, 2016

And the attacks listed there rely on the MAC, which as you point out, Vim omits anyway. AND they are timing attacks, which if you have the capability to carry out on Vim's encryption, you could do much easier and more effective attacks anyway as I point out above.

The set of attacks that apply against "we fucked up our protocol and shipped something other than Encrypt-Then-MAC" is much, much smaller than the set of attacks that apply against "we don't authenticate at all".

The most trivial example of an attack against unauthenticated encryption was Serge Vaudenay's CBC padding oracle attack against CBC mode (which is similar to CFB mode).

[everything @tarcieri said]

100% agreement. Encryption for the sake of encryption is a bad model. It should have a defined purpose within an explicitly defined threat model in terms of how real users would use the system.

Vim would be much better off migrating away from offering this "feature" and encouraging Full Disk Encryption instead, i.e. dm_crypt.

@chrisbra

This comment has been minimized.

Copy link
Member

commented Feb 19, 2016

Vim would be much better off migrating away from offering this "feature" and encouraging Full Disk Encryption instead, i.e. dm_crypt.

That only works, if you are allowed to (e.g. have the privilige) full encrypt your system and full encryption is available on your system. I am not sure about the latter for Windows, since Truecrypt has been abandonded two years ago.

Having said that, I am sure, nobody would be opposed to improvements to the crypt feature. But code speaks louder than words...

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

Having said that, I am sure, nobody would be opposed to improvements to the crypt feature. But code speaks louder than words...

Bad encryption isn't worth providing. If the encryption is broken, you should follow TrueCrypt's example and switch to a read-only mode which allows files encrypted in vim's broken, proprietary on-disk format to be migrated to, e.g. GPG:

http://truecrypt.sourceforge.net/

re: code, NeoVim already purged this same feature. Their patch could be adopted upstream:

neovim/neovim#694

@chrisbra

This comment has been minimized.

Copy link
Member

commented Feb 19, 2016

I am not sure, why you are always mention Neovim. We are not Neovim here and we are not talking about a broken encryption here.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

@chrisbra I think I've done a fairly good job describing why the cryptography vim ships is broken. If you have an actual technical argument against anything I've said, please let me know.

But I'll ask you again: Why do you think it's a good idea to keep shipping non-interoperable, obsolete crypto full of sharp edges?

@chrisbra

This comment has been minimized.

Copy link
Member

commented Feb 19, 2016

@tarcieri
First of all, what do you mean with broken? Please show an example of how to recover an encrypted file from Vim that is significant better than brute forcing.. Until this is not done, you should not call it broken.

Second, you can't seriously suggest removing a feature, some users are still requiring and tell the people to move on to full disk encryption, if this is in fact not a possible alternative to everybody and last, as has been already said, Vim encryption is meant to avoid other people, who don't have the key, from reading the text. It does not have the goal of protecting manipulation of the text.
Now you might call this a weakness, and I am sure we can all agree on that.

But that does not mean, we should go ahead and simply drop it. But we will accept improvements to the existing code.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

First of all, what do you mean with broken?

I have already been through this in detail. Are you actually reading what I'm saying?

  1. It's not just using malleable, unauthenticated cryptography which is bad because of the very limited number of threats it protects against...
  2. It's using a weak password-based key derivation algorithm which is vulnerable to brute force attacks
  3. It's using a cipher (Blowfish) whose creator does not recommend using it anymore: "At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead." -- Bruce Schneier
  4. It's using a cipher with a small block size (64-bits)
  5. It's using a cipher vulnerable to reflectively weak key attacks
  6. It's using an on-disk format which is incompatible with anything except vim

Please show an example of how to recover an encrypted file from Vim that is significant better than brute forcing.

Did you literally just propose a "crypto contest"?

http://thoughtcrime.org/blog/telegram-crypto-challenge/

Unauthenticated cryptography is widely known to be broken. The burden of proof is not on me here. Perhaps there are some PhD candidates who are interested in going to town on vim crypto for their thesis somewhere, however.

Second, you can't seriously suggest removing a feature

I'm suggesting moving it to a read-only capacity, much like other tools whose creators actually recognized were broken and were responsible enough to take this measure, which I already linked, but I'll link again:

http://truecrypt.sourceforge.net/

some users are still requiring and tell the people to move on to full disk encryption

Actually I recommended using GPG for the cases where this feature would actually be helpful. In general I recommend everyone use full disk encryption in addition to that. I also mentioned local file disclosure attacks, which FDE won't help you with.

if this is in fact not a possible alternative to everybody and last, as has been already said, Vim encryption is meant to avoid other people, who don't have the key, from reading the text.

Sure hope those people are using strong passwords. Your KDF is shit.

But that does not mean, we should go ahead and simply drop it. But we will accept improvements to the existing code.

Hey let's back up to this one:

I am not sure, why you are always mention Neovim.

I mention Neovim because it's a fork of this same project who encountered this same problem and did the right thing. I hope vim does the same.

@chrisbra

This comment has been minimized.

Copy link
Member

commented Feb 19, 2016

On Fr, 19 Feb 2016, Tony Arcieri wrote:

First of all, what do you mean with broken?

I meant this. Are you actually reading what I'm saying?

Yes and I only saw some claims. You seem to like Bruce Schneier, so
quoting from him:

"Breaking a cipher simply means finding a weakness in the cipher that
can be exploited with a complexity less than brute-force."

This has neither been claimed nor proven, so I ask not to call it
broken.

  1. It's not just using malleable, unauthenticated cryptography which is bad because of the very limited number of threats it protects against...
  2. It's using a weak password-based key derivation algorithm which is vulnerable to brute force attacks

possibly valid points.

  1. It's using a cipher (Blowfish) whose creator does not recommend
    using it anymore: "At this point, though, I'm amazed it's still being
    used. If people ask, I recommend Twofish instead." -- Bruce Schneier

I don't see it as a problem, for as long as it is not broken (see
above).

  1. It's using a cipher with a small block size (64-bits)
  2. It's using a cipher vulnerable to reflectively weak key attacks

also possibly valid points.

So please go ahead and propose a patch to address issues 1-2 and 4-5

  1. It's using an on-disk format which is incompatible with anything except vim

Does not matter for the actual discussion.

Please show an example of how to recover an encrypted file from Vim that is significant better than brute forcing.

I'm suggesting moving it to a read-only capacity, much like other tools whose creators actually recognized were broken and were responsible enough to take this measure, which I already linked, but I'll link again:

http://truecrypt.sourceforge.net/

Ironically truecrypt has not been broken until now. The whole truecrypt
thing is still mysterious and as far as i know, there have been no major
weeknesses found in it in the audit that has been done. Abandoning it
was just a major PIA for all users and left them without a working safe
encryption method.

some users are still requiring and tell the people to move on to
full disk encryption, if this is in fact not a possible alternative
to everybody and last, as has been already said, Vim encryption is
meant to avoid other people, who don't have the key, from reading
the text.

Sure hope those people are using strong passwords.

Using strong passwords is always a good suggestion ;)

Your KDF is shit.

Please watch your mouth.

But that does not mean, we should go ahead and simply drop it. But
we will accept improvements to the existing code.

Hey let's back up to this one:

I am not sure, why you are always mention Neovim.

I mention Neovim because it's a fork of this same project who
encountered this same problem and did the right thing. I hope vim does
the same.

And I still think, it was an error to remove it without proof that it
has been actually broken.

Best,

Christian

Wie man sein Kind nicht nennen sollte:
Mike Roskoop

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

You seem to like Bruce Schneier

He's ok, but I prefer Dan Boneh:

https://www.coursera.org/learn/crypto/lecture/q0h9g/semantic-security

Semantic security is the modern bar for a secure cipher. It's already been demonstrated that Blowfish lacks this property, at least for the set of reflectively weak keys:

https://www.iacr.org/archive/fse2007/45930168/45930168.pdf

Your (extremely naive) KDF does not take these into account, although its lack of key stretching / strengthening is a much larger issue.

@brammool

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2016

This discussion is pointless, I'm closing it.

Please don't throw words like "broken" around, you clearly have a distorted world view. If I encrypt a file with Vim my sister can't read it and has no way to make it readable. Therefore it works just fine.

@brammool brammool closed this Feb 19, 2016

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 19, 2016

This is unfortunate. As Tony mentioned, there are serious problems with the Vim cryptmethod that make it highly suspect:

  • The encryption is not authenticated.
  • The KDF uses a fast hashing algorithm.
  • It uses Blowfish, instead of Twofish, or even AES.
  • It uses a non-standard encrypted storage format.

Vim's encryption is susceptible to:

  • Bitflipping attacks.
  • Chosen ciphertext attacks.
  • Fast GPU or FPGA password cracking to recover the key.

cryptmethod=blowfish was horribly broken, so cryptmethod=blowfish2 was created with a rewrite of blowfish.c. While it was a step in the right direction, it is still horribly broken, and needs to be fixed or removed entirely.

There are some well-documented cases in SSL, IPSEC, Kerberos, and many other software projects where unauthenticated encryption led to disastrous attacks. It probably wouldn't hurt to read the Wikipedia article on authenticated encryption to understand what you're up against with the current implementation.

@paragonie-scott

This comment has been minimized.

Copy link

commented Feb 19, 2016

Please don't throw words like "broken" around, you clearly have a distorted world view.

No, this isn't clear to me. Please explain more.

  • How does "our cryptosystem is not IND-CCA secure" not qualify for "broken" in respect to crypto?
  • Who on this Earth can claim to have a worldview that isn't distorted? Is this worth mentioning?

If I encrypt a file with Vim my sister can't read it and has no way to make it readable. Therefore it works just fine.

If you encrypt your hard drive and/or your homedir, your sister also can't read it. But that's not very useful.

@tarruda

This comment has been minimized.

Copy link

commented Feb 19, 2016

Hi @brammool / @chrisbra

Consider the following scenario: Imagine Alice(someone with little/no encryption knowledge) is looking for a simple way to protect a file, then she reads about the -x option:

-x Use encryption when writing files. Will prompt for a crypt key.

After encrypting a few files and seeing the resulting cyphertext, Alice makes the false assumption that it is impossible for anyone to read the data without knowing the password, so she starts using vim -x to encrypt everything.

After encrypting some company-sensitive files, her laptop breaks and she sends it to Bob, a computer technician. Bob decides to look inside the HD and finds a directory containing all her encrypted files.
Since Vim is installed and Bob knows it uses SHA256 as KDF, he decides to give it a shot at brute forcing with a popular password cracker with GPU support. If Alice has a weak password(which is not so uncommon for non-technical users), there's a good chance Bob will break the encryption.

I think the point @atoponce / @tarcieri are trying to make is that no encryption is better than weak encryption, as it can give a false sense of security to users.

I know that Vim is free and offers no warranty, and removing this feature may not be an option. But a fair warning at the documentation for the -x option wouldn't hurt:

-x Use encryption when writing files. Will prompt for a crypt key. Don't use it for highly-sensitive
data as the encryption used contains some known vulnerabilities: (link to this issue or some
documentation that explains the problem)

@vim-ml

This comment has been minimized.

Copy link

commented Feb 19, 2016

On Friday, February 19, 2016 at 9:19:18 AM UTC-6, Thiago de Arruda wrote:

Since Vim is installed and Bob knows it uses SHA256 as KDF, he decides to give it a shot at brute forcing with a popular password cracker with GPU support. If Alice has a weak password(which is not so uncommon for non-technical users), there's a good chance Bob will break the encryption.

I think the point @atoponce / @tarcieri are trying to make is that no encryption is better than weak encryption, as it can give a false sense of security to users.

I know that Vim is free and offers no warranty, and removing this feature may not be an option. But a fair warning at the documentation for the -x option wouldn't hurt:

-x Use encryption when writing files. Will prompt for a crypt key. Don't use it for highly-sensitive

         data as the encryption used contains some known vulnerabilities: (link to this issue or some

         documentation that explains the problem)

OK, I'll concede the point about the weak KDF. That could be a lot slower to improve the situation for weaker passwords. It could be a really really nice patch to add a new cryptmethod, or maybe a new cryptkdf, option that supports something like scrypt.

But, AFAIK Blowfish as an algorithm is not "broken", especially regarding the expected uses here. There are some attacks that are possible with 2^34 (several BILLION) known or chosen plaintexts, which will certainly not be the case when attacking one or two files encrypted by a Vim user at some point. And there are apparently problems with very large (gigabyte sized) plaintexts; again this would be very unlikely for a Vim user to have.

Admittedly I'm a bit out of my area of expertise here, and I certainly would not feel qualified to actually write the crypto code, but throwing out a perfectly good algorithm for reasons that sound cargo-cultish rather than a reasoned thought process about the expected use cases seems less than ideal.

That said, I think I'd like to see something like this in a perfect world:

  1. A new cryptmethod, that does the encryption through a 3rd-party library. Bram is awesome, but I don't think he's a crypto expert. And with a 3rd-party library we'll get any security fixes for free, plus there will be plenty more people looking at the code to find issues.
  2. Options for selecting/tuning the KDF. SHA256 is not a great one to use anymore, unless we use a heck of a lot more iterations. Something designed to be slow would be much better.
  3. Vim should automatically select the strongest available cryptmethod at startup and a reasonably strong set of KDF options (maybe tuned to take 1 second on the current hardware, for example).
  4. Possibly, an option to automatically upgrade the cryptmethod to the current setting, if editing a file using an older weaker cryptmethod (especially useful for original blowfish or even zip encryption).
  5. I still don't understand why "at rest" data would need a MAC from a confidentiality standpoint, but since it could help you discover whether the data is corrupt, sure, we could add a MAC to the new cryptmethods.
  6. Probably a warning when setting cryptmethod that is not the strongest available would be appropriate. But it should be kept for backwards compatibility, e.g. if you need access to the file on systems where you can't upgrade your Vim. Plus you may not always have the external library available.
@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 19, 2016

But, AFAIK Blowfish as an algorithm is not "broken", especially regarding the expected uses here. There are some attacks that are possible with 2^34 (several BILLION) known or chosen plaintexts, which will certainly not be the case when attacking one or two files encrypted by a Vim user at some point. And there are apparently problems with very large (gigabyte sized) plaintexts; again this would be very unlikely for a Vim user to have.

Blowfish the algorithm is secure. Unauthenticated encryption regardless of the algorithm is vulnerable to attacks.

That said, I think I'd like to see something like this in a perfect world:

  1. AES-GCM or AES-CTR-HMAC-SHA256 would be the "best practice" encryption method.
  2. scrypt or PBKDF2, with appropriate hardness settings is really what should be used here.
  3. If you must have other options, then XSalsa20, AES, Twofish, and Serpent are valid, modern, cryptographically secure choices.
  4. No comment.
  5. Vim encrypted data could be stored in Dropbox, Google Drive, NFS or Samba shares, emailed to a recipient, uploaded to Github, ...
  6. Probably best just to deprecate it, starting with read-only, eventually removing it in favor of gnupg.vim.
@paragonie-scott

This comment has been minimized.

Copy link

commented Feb 19, 2016

This issue really should be re-opened.

@tarcieri

This comment has been minimized.

Copy link

commented Feb 19, 2016

This discussion is pointless, I'm closing it.

This discussion certainly does seem to be pointless then!

Please don't throw words like "broken" around, you clearly have a distorted world view.

So instead of technical counterarguments, you're making comments about my "world view"?

You are absolutely unqualified to be working on cryptography. Let's review your past statements:

It does not have the goal of protecting manipulation of the text, that is something else. You could add a checksum even when not using encryption. I believe it's called signing.

For this case, the appropriate mechanism would be a message authentication code, or MAC. Digital signatures are an asymmetric primitive, and from the handwavy descriptions of your intended threat model this is not the indented use case.

Adding a checksum actually makes breaking the encryption easier. I don't
know by how much, it depends on a way to check if the decription seemed
to have worked.

You have everything backwards here. We are proposing authenticating the ciphertext, a.k.a. an encrypt-then-MAC construction. In no way does this make "breaking the encryption easier". To the contrary failure to authenticate the ciphertext leads to a class of ciphertext malleability attacks we keep describing. If you think a MAC makes it easier to detect a potential decrypt, sure, but unless you're encrypting uniformly random data you can identify candidate decrypts using Dieharder/Ent-style statistical tests. Compression definitely will not mask this: only a secure symmetric cipher can.

That can be avoided by performing another operation first, e.g. compressing the text.

Compressing data prior to encryption can lead to compression sidechannel attacks (e.g. CRIME, BREACH). It is definitely not recommended and will do nothing to help improve the confidentiality or integrity of the data.

@vim-ml

This comment has been minimized.

Copy link

commented Feb 19, 2016

On Friday, February 19, 2016 at 10:26:36 AM UTC-6, Tony Arcieri wrote:

failure to authenticate the ciphertext leads to a class of ciphertext malleability attacks we keep describing

Please describe one such attack, that applies to data at rest, where the attacker is not able to have the system to decrypt arbitrary data, as is the case here. If I understand properly the malleable data attacks you've described so far depend on the system trying to decrypt subtly modified ciphertexts using the real key for a wide range of ciphertexts.

I'm guessing you won't be able to convince the user to enter a password to decrypt thousands or millions of variations on their file in Vim.

And if you can, you're probably running a process on the user's system, in which case you should just capture their password, or install a plugin to dump any previously encrypted file to plaintext, and be done with it.

If there is a weakness here that will theoretically allow someone to scrape a Vim-encypted file off a discarded USB stick, and somehow read it, then I will certainly call it broken and will advocate for adding authentication.

As it stands, in Vim's particular case, it seems like a "nice to have" feature, not "required for confidentiality".

@tarruda

This comment has been minimized.

Copy link

commented Feb 19, 2016

That said, I think I'd like to see something like this in a perfect world:

You can already get a very nice editor-encryption setup with vim-gnupg. These feature's don't need to be embedded into the core.

@odabrunz

This comment has been minimized.

Copy link

commented Feb 19, 2016

+1 for all people on this thread that work constructively to understand and assess possible threats, and that suggest possible paths of action. This goes to all main contributors, even if there are some hastened reactions and some entrenching here and there.

Special mentions:

+1 for @vim-ml (Ben), for constructiveness and the 6-points plan at improving Vim crypto (even if not completely easy to do).
+1 for @atoponce, for giving several helpful descriptions and answers, including a description of a possible attack scenario.

@tarruda

This comment has been minimized.

Copy link

commented Feb 19, 2016

But as has been stated before, I do not see how the attacker can observe the results of Vim decrypting the ciphertext without already having breached the security of the machine where Vim is running on

If the encrypted file is stored in a shared server(or alternatives suggested by @atoponce: Dropbox, Google Drive, NFS, Samba shares) a sysadmin could brute force a weak password since Vim uses sha256 as KDF. Then it would simply be a matter of encrypting the desired code(eg: an uncovered modeline bug) and replacing the real ciphertext with the fabricated one. When the user restores the backup on his own machine and decrypts the file, the code would execute since there's no MAC validation)

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 19, 2016

If the encrypted file is stored in a shared server(or alternatives suggested by @atoponce: Dropbox, Google Drive, NFS, Samba shares) a sysadmin could brute force a weak password since Vim uses sha256 as KDF.

See #639 for replacing the KDF with a more appropriate implementation.

@odabrunz

This comment has been minimized.

Copy link

commented Feb 19, 2016

If the encrypted file is stored in a shared server(or alternatives suggested by @atoponce: Dropbox, Google Drive, NFS, Samba shares) a sysadmin could brute force a weak password since Vim uses sha256 as KDF.

Yes, and this has been acknowledged by @vim-ml.

Edit: Just to clarify: my comment was aimed at how bit-flipping attacks could work in the case that the attacker needs to observe some of the effects of Vim decrypting the ciphertext, in order to craft his attack. I agree that the attack on the KDF can work without observing Vim's decryption or its results.

See #639 for replacing the KDF with a more appropriate implementation.

You were quicker.

@vim-ml

This comment has been minimized.

Copy link

commented Feb 19, 2016

On Friday, February 19, 2016 at 2:28:51 PM UTC-6, Thiago de Arruda wrote:

If the encrypted file is stored in a shared server(or alternatives suggested by @atoponce: Dropbox, Google Drive, NFS, Samba shares) a sysadmin could brute force a weak password since Vim uses sha256 as KDF. Then it would simply be a matter of encrypting the desired code(eg: an uncovered modeline bug) and replacing the real ciphertext with the fabricated one. When the user restores the backup on his own machine and decrypts the file, the code would execute since there's no MAC validation)

Except, if the nefarious admin has brute-forced the password to re-encrypt with desired modifications, then they'll just recalculate the MAC as well, right? So MAC wouldn't help for this attack. Better KDF for sure, though; we can't expect everyone to use 100+ bits of entropy in a password :-)

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 19, 2016

Dan Boneh who provides Coursera crypto courses from Stanford has some lectures about authentication encryption, which might be worth watching for some in this thread:

https://class.coursera.org/crypto-preview/lecture/33
https://class.coursera.org/crypto-preview/lecture/34
https://class.coursera.org/crypto-preview/lecture/35
https://class.coursera.org/crypto-preview/lecture/36
https://class.coursera.org/crypto-preview/lecture/37
https://class.coursera.org/crypto-preview/lecture/38
https://class.coursera.org/crypto-preview/lecture/40

While many of those lectures are using TLS examples, they are generic enough to apply to any crypto implementation. Chosen ciphertext attacks as one possible avenue. If you haven't taken the course from him, I STRONGLY recommend it. It's a free online course that anyone can take, and starts out simple enough that anyone should be able to make heads and tails of the lectures and the assigned homework. The motivation for the class is simple- people who design cryptographic software think they might be doing things correctly, when in reality, they're doing everything incorrectly.

Moxie Marlinspike also blogged back in 2011 about the "Cryptographic Doom Principle", which basically says you should always Encrypt-then-MAC. Anything else (which includes unauthenticated encryption) will lead you to doom:

http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/
https://news.ycombinator.com/item?id=9374842

TL;DR- Unauthenticated encryption is weak encryption. Authenticated encryption is stronger.

@tarruda

This comment has been minimized.

Copy link

commented Feb 20, 2016

Except, if the nefarious admin has brute-forced the password to re-encrypt with desired modifications, then they'll just recalculate the MAC as well, right? So MAC wouldn't help for this attack. Better KDF for sure, though; we can't expect everyone to use 100+ bits of entropy in a password :-)

👍 If someone brute forces the password, then the MAC is not helpful at all(completely missed that obvious fact in my comment).

Note that my encryption knowledge is very superficial. I wouldn't be surprised if a specialist easily finds other exploits to Vim's encryption, considering it has so many known vulnerabilities.

@fritzophrenic

This comment has been minimized.

Copy link

commented Feb 20, 2016

Ben here, from the mailing list.

Note that my encryption knowledge is very superficial.

Yeah, sadly mine too. But maybe I'll take a crack at integrating a library one of these days. I feel safer using crypto code than writing it.

Maybe this is my inexperience talking, but would it be possible to verify the correctness of Vim's blowfish implementation, by giving the same inputs and operating mode to a 3rd-party library and seeing if the outputs match? If that's possible, would that make Vim's codebase less ominous?

I wouldn't be surprised if a specialist easily finds other exploits to Vim's encryption, considering it has so many known vulnerabilities.

What known vulnerabilities? So far this thread has not pointed to any in particular. I'm going to go look at those lectures @atoponce linked, maybe I'll find something more convincing in there. But at the moment, the closest I've seen to a vulnerability relies on twiddling bits to affect the decrypted file in predictable ways which should be very very hard. And the "doom principle" as far as I know requires an oracle of some kind to apply. Where Vim is used, you won't have that.

Maybe here is something which I was able to think of where a MAC could help: assume at some point a buffer overflow is discovered in the undo file or swap file parser. Since these are encrypted along with the file itself, perhaps a bit could be swapped in the right location to trigger that overflow. And then mumble mumble and the attacker could read a memory dump from Vim, thereby getting the password. Is this the sort of attack y'all had in mind? It does rely on an as-yet undiscovered and possibly non-existent bug to actually be possible...

@tarruda

This comment has been minimized.

Copy link

commented Feb 20, 2016

What known vulnerabilities? So far this thread has not pointed to any in particular. I'm going to go look at those lectures @atoponce linked, maybe I'll find something more convincing in there. But at the moment, the closest I've seen to a vulnerability relies on twiddling bits to affect the decrypted file in predictable ways which should be very very hard. And the "doom principle" as far as I know requires an oracle of some kind to apply. Where Vim is used, you won't have that.

Here's what @tarcieri pointed out:

  • It's not just using malleable, unauthenticated cryptography which is bad because of the very limited number of threats it protects against...
  • It's using a weak password-based key derivation algorithm which is vulnerable to brute force attacks
  • It's using a cipher (Blowfish) whose creator does not recommend using it anymore: "At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead." -- Bruce Schneier
  • It's using a cipher with a small block size (64-bits)
  • It's using a cipher vulnerable to reflectively weak key attacks

As someone with little knowledge on the subject, I can't think of how these may be used in attacks except for the weak KDF(#639) exploit to brute force weak passwords. But there's something else @tarcieri pointed out as a problem that, while not directly related to security, should be taken into consideration anyway:

  • It's using an on-disk format which is incompatible with anything except vim

If your are serious about integrating Vim with a 3rd-party solution, I recommend looking into gnupg/gnupg.vim. IMO it already provides a rather complete crypto setup for Vim, but as @vim-ml pointed out, there's the disadvantage of missing swap/undofile features

One way to fix this disadvantage is to have Vim expose a hook for writing swap/undofiles, such as an user-defined command to pipe the swap/undofile contents to/from, instead of writing/reading directly the filesystem. Such command would be called whenever Vim needs to read/write a certain block of the swap/undofile.

Such swap/undofile hooks would allow a plugin like vim-gnupg could use a robust existing solution like gnupg to manage swap/undo without having these features baked into the core.

@odabrunz

This comment has been minimized.

Copy link

commented Feb 20, 2016

Maybe this is my inexperience talking, but would it be possible to verify the correctness of Vim's blowfish implementation, by giving the same inputs and operating mode to a 3rd-party library and seeing if the outputs match? If that's possible, would that make Vim's codebase less ominous?

It is not possible, as a random initialization vector must be used, so that the ciphertext output is different when encrypting the same block of plaintext again with the same key. Anything else could be exploited in a cryptoanalysis.

@fritzophrenic

This comment has been minimized.

Copy link

commented Feb 20, 2016

On Feb 20, 2016 8:46 AM, "Olaf Dabrunz" notifications@github.com wrote:

Maybe this is my inexperience talking, but would it be possible to
verify the correctness of Vim's blowfish implementation, by giving the same
inputs and operating mode to a 3rd-party library and seeing if the outputs
match? If that's possible, would that make Vim's codebase less ominous?

It is not possible, as a random initialization vector must be used, so
that the ciphertext output is different when encrypting the same block of
plaintext again with the same key. Anything else could be exploited in a
cryptoanalysis.

Right, but we have access to the code driving it. I assume the IV can be
set by the user of crypto libraries; at least, a quick search of libgcrypt
docs shows a few functions for setting the IV. So we should be able to try
both implementations with the same IV. I was actually counting that among
the "same inputs".

It might be easier to just try decrypting Vim's output with code using a
library, and vice versa. I think that would probably be almost as good a
test.

@atoponce

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

I assume the IV can be set by the user of crypto libraries; at least, a quick search of libgcrypt docs shows a few functions for setting the IV. So we should be able to try both implementations with the same IV. I was actually counting that among the "same inputs".

Outside of testing, the IV should be unpredictable. It can be created by reading the system CSPRNG.

@fritzophrenic

This comment has been minimized.

Copy link

commented Feb 20, 2016

On Feb 20, 2016 10:49 AM, "Aaron Toponce" notifications@github.com wrote:

I assume the IV can be set by the user of crypto libraries; at least, a
quick search of libgcrypt docs shows a few functions for setting the IV. So
we should be able to try both implementations with the same IV. I was
actually counting that among the "same inputs".

Outside of testing, the IV should be unpredictable. It can be created by
reading the system CSPRNG.

Agree. In case it wasn't clear when I mentioned setting the IV to a
specific value, I was only talking about testing. It sounds like it's
possible to sanity-check Vim's blowfish for obvious mistakes by comparing
Vim's output to a library implementation, or by decrypting each other's
output. Would you agree that's worth doing, assuming the blowfish code is
not dropped entirely?

@fritzophrenic

This comment has been minimized.

Copy link

commented Feb 20, 2016

On Feb 20, 2016 7:31 AM, "Thiago de Arruda" notifications@github.com
wrote:

If your are serious about integrating Vim with a 3rd-party solution, I
recommend looking into gnupg/gnupg.vim. IMO it already provides a rather
complete crypto setup for Vim, but as @vim-ml pointed out, there's the
disadvantage of missing swap/undofile features

One way to fix this disadvantage is to have Vim expose a hook for writing
swap/undofiles, such as an user-defined command to pipe the swap/undofile
contents to/from, instead of writing/reading directly the filesystem. Such
command would be called whenever Vim needs to read/write a certain block of
the swap/undofile.

Now that's an interesting idea. What if Vim grew a 'cryptprg' option to use
in place of its own crypto code anywhere it would have been used? Plugin
code needed would be minimal.

I think it should be in addition to a stronger KDF at the very least. There
may still be some advantages in portability though, for adding another
lib-based cryptmethod, for those who use Vim on multiple systems.

@odabrunz

This comment has been minimized.

Copy link

commented Feb 20, 2016

What known vulnerabilities? So far this thread has not pointed to any in particular. I'm going to go look at those lectures @atoponce linked, maybe I'll find something more convincing in there. But at the moment, the closest I've seen to a vulnerability relies on twiddling bits to affect the decrypted file in predictable ways which should be very very hard. And the "doom principle" as far as I know requires an oracle of some kind to apply. Where Vim is used, you won't have that.

Here's what @tarcieri pointed out:

  • It's not just using malleable, unauthenticated cryptography which is bad because of the very limited number of threats it protects against...

Authenticated cryptography (implemented "right") can protect against chosen ciphertext attacks, which includes at least one mode of bit flipping attacks.

The feasibility of these attacks against Vim has not been made clear yet.

In one attack mode, an attack requires the observation of some of the results of decrypting the chosen ciphertexts. In the attacks I know of, many such chosen ciphertext decryptions need to be observed.

AFAICT, the concern usually is that an ingenious attacker may be able to launch a chosen ciphertext attack by using Vim as a decryption oracle in a way that we do not expect. So for this reason we should add the additional security provided by authenticated cryptography (done "right") to protect against these attacks, even if we cannot imagine how they can be launched against Vim.

So no demonstrated exploit, but this is at the last line of defense. Difficult to say how strong that line is. No doubt it would be better to improve the defenses.

In another attack mode, the attacker has (partial) knowledge of the plaintext, and can craft a ciphertext that induces a malicious plaintext.

Exploits have been demonstrated for specific encryption modes (when authenticated encryption is done "wrong"). But the affected plaintext needs to be located in a specific position in the text.

This is a very interesting attack vector, and it may either lead to a quick and simple exploit, or not.

This is the most convincing argument given (by @atoponce) for using authenticated encryption (done "right") soon.

  • It's using a weak password-based key derivation algorithm which is vulnerable to brute force attacks

The KDF is too fast, and this makes brute force attacks run faster.

To understand if this amounts to a currently feasible exploit, according to the best of our knowledge, we would need to know how fast a brute force attack would actually be in Vim's case (find out key length used in Vim and fastest achievable throughput for breaking attempts).

Also, it may play a role that Vim does not enforce that users use strong enough keys.

I believe nobody objected that the KDF should be changed.

  • It's using a cipher (Blowfish) whose creator does not recommend using it anymore: "At this point, though, I'm amazed it's still being used. If people ask, I recommend Twofish instead." -- Bruce Schneier

Not a description of a vulnerability or an exploit.

But a newer crypto algorithm, designed by one of the leading experts in the field, no doubt with better defenses against the growing number of attacks, and recommended over one of that expert's older designs, of course means that Vim should probably move on and use one of the currently recommended algorithms (Twofish, AES, ...), at least as a better default.

  • It's using a cipher with a small block size (64-bits)

This can be exploited in cryptoanalysis: when more than 4GB of plaintext are encrypted with the same key, it becomes probable that two ciphertext blocks are identical, even if the corresponding plaintext blocks are different. This reveals some properties of the key.

Edit: It is 32GB of plaintext, not 4GB. (2^32 plaintext / ciphertext blocks, each with 64 bits = 8 bytes.)

Although I have not seen an exploit based on this, I have no doubt that a cryptoanalyst can create one.

An exploit would require more than one cipherblock collision. So a large number of cipherblocks needs to be intercepted and saved. Would be interesting to know how many.

The feasibility has not been demonstrated, but it only requires ciphertext interception, which is a probable attack scenario (as has been mentioned: saving files on shared or remote storage such as Dropbox, ...). And with cipherblocks created on every write to the edited file or the swapfile or undofile during editing, more ciphertext may be created than we may think now.

To understand the feasibility of an exploit, we would need to quantify how much ciphertext would be needed for an exploit, and how much ciphertext would be generated by Vim usage scenarios (worst case, typical case).

Without a real feasibility analysis, just from a rough guesstimate, this seems to be the most urgent concern. It is another reason to move on to a newer algorithm. Twofish and AES (and all other algorithms in the NIST AES contest) use 128 bit blocks.

Edit: 128 bit blocks require 2^64 * 128 bit = 256 EB of plaintext / ciphertext for a probable cipherblock collision.

  • It's using a cipher vulnerable to reflectively weak key attacks

AFAIU, a brute force key recovery attack (which does not require the participation of Vim) is feasible on any ciphertext that Vim encrypted with blowfish using one of the many weak keys.

The problem is to find out if a given encryption uses a weak key, so that the brute force attack becomes feasible. Finding this out still requires to use Vim as a sort of oracle in a chosen plaintext attack or a known plaintext attack, which uses many attempts.

To understand the urgency of this better, it would be interesting to know how probable the generation of a weak key is in Vim's case.

My guess is that this is less pressing than the block size problems, because the ratio of weak keys to good keys may be quite small, and because Vim still needs to be used as an oracle.

Still another good reason to use a more modern encryption.

  • It's using an on-disk format which is incompatible with anything except vim

Not an exploit.

Interoperability is probably a concern for some people.

But one of the advantages of having a built-in text encryption / decryption facility is that this feature does not depend on the availability of an encryption library on the many platforms supported by Vim.

Vim can read and write its own encrypted texts on most or all flavors of Unix, Windows, Mac, VMS, BeOS, Amiga etc., out of the box.

As mentioned before, using an external encryption program means that swapfiles and undofiles need to be disabled for editing encrypted texts. So this is not a full-featured alternative to built-in encryption or an encryption library.

But built-in encryption of course comes at the cost of maintaining the crypto implementation in Vim, which essentially needs to be done by a cryptology expert.

Also, it seems better to move on to more modern encryption algorithms. But maintaining more crypto code also takes more time and requires more expertise.

And when using a crypto library, Vim can benefit from audits that are done on the library (would need to check if that is actually done though). It seems less likely that a crypto audit is done on the crypto code in Vim, but it is not impossible.

I am counting

  • zero demonstrated exploits
  • one convincing argument for a possible threat (unauthenticated encryption -> deterministic chosen ciphertext attack triggering a bug)
  • one seemingly urgent concern (block size) where the ratio of ciphertext required for an exploit to probably interceptable ciphertext seems to be small
  • three seemingly less urgent concerns, where either Vim needs to be used as a decryption oracle, or the workload for an attack still seems to be large, but these guesstimates should be corrected by quantification
    • unauthenticated encryption -> chosen ciphertext attacks with oracle
    • fast KDF -> faster brute forcing keys
    • chosen/known plaintext attack to detect weak keys -> brute forcing weak keys

More than enough urgency and concerns to move on to newer encryption algorithms.

@odabrunz

This comment has been minimized.

Copy link

commented Feb 20, 2016

One way to fix this disadvantage is to have Vim expose a hook for writing
swap/undofiles, such as an user-defined command to pipe the swap/undofile
contents to/from, instead of writing/reading directly the filesystem. Such
command would be called whenever Vim needs to read/write a certain block of
the swap/undofile.

Now that's an interesting idea. What if Vim grew a 'cryptprg' option to use
in place of its own crypto code anywhere it would have been used? Plugin
code needed would be minimal.

If this facility is fast enough, this could be interesting.

Not good if this blocks vim for too long, swapfile / undofile updates should not make the cursor react slowly.

This may work if there is a way to keep the external program running (maybe attached via Vim's new channel facility). Haven't seen a server mode for gpg though. (Batch mode is more like an unattended mode that does only one operation.)

@tarruda

This comment has been minimized.

Copy link

commented Feb 20, 2016

Now that's an interesting idea. What if Vim grew a 'cryptprg' option to use
in place of its own crypto code anywhere it would have been used? Plugin
code needed would be minimal.

I suggest trying to find a more generic solution, such as adding events with similar semantics to BufReadCmd/BufWriteCmd, but for swap/undofiles. The *Cmd events are already by gnupg.vim, so it would be easy to extend the plugin to support swap/undofiles.

Something just came to mind: Does vim use any kind of locking mechanism to prevent memory pages(which can contain cryptographic keys) from being swapped to disk? If not, this would too be a significant vulnerability.

@fritzophrenic

This comment has been minimized.

Copy link

commented Feb 20, 2016

Now that's an interesting idea. What if Vim grew a 'cryptprg' option to use
in place of its own crypto code anywhere it would have been used? Plugin
code needed would be minimal.

I suggest trying to find a more generic solution, such as adding events with similar semantics to
BufReadCmd/BufWriteCmd, but for swap/undofiles. The *Cmd events are already by gnupg.vim,
so it would be easy to extend the plugin to support swap/undofiles.

What's the advantage of a SwapWriteCmd/UndoWriteCmd autocmd over a 'cryptprg' option? It seems that would be more work, not less, to write a suitable set of autocmds that pipe the data to an external program; and you need to be sure to set up all of them. With a single option or set of options similar to makeprg you'd just need one setting to handle any writing Vim does on encrypted files. Having Vim know that it should be treating files carefully would let it handle other things carefully, such as the locking concern (which I don't know the answer to at the moment). I doubt a plugin could handle that portion. Vim keeps its buffer contents in memory as well, so if Vim's memory gets swapped, you could have the full plaintext, not just the encryption keys.

Actually :help encryption says:

Note: The text in memory is not encrypted. A system administrator may be able
to see your text while you are editing it.

So I'd guess that's another area that needs improvement. Possibly that's more urgent than the other concerns. Not because an admin can see the text while you edit, but because that text may be available in swap space long after you are done editing.

@atoponce

This comment has been minimized.

Copy link
Author

commented Aug 25, 2016

Blowfish is a 64-bit cipher. Given the recent news with the Sweet 32 Birthday Attack on 64-bit ciphers, this bug really should be reconsidered. Not only for authenticating the ciphertext, but also completely dropping Blowfish, and using a 128-bit block cipher like AES instead.

See https://sweet32.info/

@vim-ml

This comment has been minimized.

Copy link

commented Aug 25, 2016

On Thursday, August 25, 2016 at 11:33:33 AM UTC-5, Aaron Toponce wrote:

Blowfish is a 64-bit cipher. Given the recent news with the Sweet 32 Birthday Attack on 64-bit ciphers, this bug really should be reconsidered. Not only for authenticating the ciphertext, but also completely dropping Blowfish, and using a 128-bit block cipher like AES instead.

Sweet32 relies on reading a LOT of data using the same key. It's processing HUNDREDS OF GIGABYTES of data over the course of many hours of network traffic.

If you're encrypting hundreds of gigabytes in Vim using the same key, you're using it wrong. Vim is not a full-disk encryption system, nor a network data encryption tool.

Blowfish is still useful in Vim. I agree we should add a new cipher without a bunch of caveats, and this specific issue regarding the weakness of the derived key needs fixing, but Sweet32 has nothing to do with any real-world scenario where Vim would be used.

@atoponce

This comment has been minimized.

Copy link
Author

commented Aug 25, 2016

Sweet32 is two things-

  1. A paper exploiting the Birthday Bound on 64-bit block ciphers.
  2. A proof-of-concept with a JavaScript payload on TLS and OpenVPN connections.

Users could be using Vim to encrypt data stored on network shares with the same key (NFS, Dropbox, CIFS, etc). An attacker need only passively monitor the network to capture enough Blowfish ciphertext to exploit the 64-bit weakness. As illustrated in the first point, this is actually only 32GB, which isn't outside of practicality.

The point of Sweet 32 is that 64-bit block ciphers no longer provide the necessary security margins that should be required in 2016. Just like SHA-1 isn't currently broken, well over a decade ago, cryptographers began showing that the security margins for SHA-1 were not large enough to be considered secure by modern standards, and the push was to get everyone off SHA-1. Other alternatives exist, faster and slower, that provide larger security margins than SHA-1, in general purpose settings, and everyone should be switching to those.

The same thing is being discussed with Sweet 32. It's time to stop using 64-bit block ciphers, like 3DES and Blowfish, and move to ciphers with larger security margins.64-bit block ciphers just don't give is the security we need in today's modern computing.

@brammool

This comment has been minimized.

Copy link
Contributor

commented Aug 25, 2016

Any encryption can be broken using a key logger.
Most attacks rely on guessing or stealing passwords.
Making the encryption stronger doesn't help much.
Would still be nice to add one, just to stop people complaining.
Adding 2-factor authentication would help more. A lot more.

@tarcieri

This comment has been minimized.

Copy link

commented Aug 25, 2016

@brammool everything else aside, the current implementation makes it trivial to brute force passwords. (That said, you attitude seems a bit "security is hard, let's go shopping!")

Since the home-brewed "PBKDF" (I use that term rather loosely in this context) it uses is so weak, It would be pretty easy to write a vimcrypt password cracker that performs standard JtR/hashcat-style generation routines and performs statistical randomness tests on the decrypts.

The real problem isn't just Blowfish, it's that all of the parts of the system are poorly designed and weak, making the job of an attacker that much easier.

@atoponce

This comment has been minimized.

Copy link
Author

commented Aug 25, 2016

@brammool I'm not complaining. If I had the time, or the expertise, I would submit a patch. But I don't. So instead, I did my civic responsibility on submitting a vulnerability to the project, and I've remained calm and logical throughout this discussion. But I will admit, that it's quite frustrating to raise awareness of the security problems, only for it to be defended by those who are not experts in the security field. The vibe I'm getting, is we're too lazy to fix it. Again, if I could submit the patch, I would.

These are two very serious bugs (#638 and #639). It's 2016.

  • Blowfish, per Schneier himself, should not be used as an encryption algorithm.
  • Encryption should be authenticated. Always.
  • Standardized KDFs with appropriate cost factors should be used for key derivation.

I love this editor. I only want to see it improve. I hope it does.

@fritzophrenic

This comment has been minimized.

Copy link

commented Aug 26, 2016

On Aug 25, 2016 4:49 PM, "Aaron Toponce" notifications@github.com wrote:

@brammool I'm not complaining. If I had the time, or the expertise, I
would submit a patch. But I don't. So instead, I did my civic
responsibility on submitting a vulnerability to the project, and I've
remained calm and logical throughout this discussion.

Thank you on all those counts.

But I will admit, that it's quite frustrating to raise awareness of the
security problems, only for it to be defended by those who are not experts
in the security field. The vibe I'm getting, is we're too lazy to fix it.
Again, if I could submit the patch, I would.

I will clarify my argument.

I am not suggesting there is nothing to fix. I think Vim's crypto is too
weak for it to be very useful for important data. The main reason for that
is the KDF; a password will need to be fully random and very long to offer
any security. I am much less worried about the block length. Earlier in the
thread someone mentioned this attack was possible with a lot of data. Now
we have a better idea of the size of data needed. I do not find it likely
that someone will be encrypting multiple gigabytes of data in Vim. But
that's a caveat on the encryption. I don't like encryption with caveats.

The other possible but unproven attacks involve using Vim as an Oracle. I
am not very concerned about these. But again, I don't like encryption with
caveats.

So anyway: I want to see new, modern encryption in Vim. I want it
implemented via a well-known library or with hooks to allow setting up an
external program. I want to see the existing crypto code deprecated,
requiring the user to force-save past a warning about using outdated
crypto. I want Vim to default to the strongest method it supports.

But I don't want the old crypto stripped out entirely. Being able to read
old files is important. Being able to share files with old Vim installs you
can't touch is useful. Libraries don't necessarily support all the systems
Vim does; I want to see a better KDF baked into Vim in addition to whatever
comes with the library, so that the feature can be used more safely on
systems without library support.

Discouraging the use of the outdated crypto is good. It definitely should
not be used for large files. But I have not been convinced it is necessary
to remove it entirely.

These are two very serious bugs (#638 and #639). It's 2016.

Blowfish, per Schneier himself, should not be used as an encryption
algorithm.
Encryption should be authenticated. Always.
Standardized KDFs with appropriate cost factors should be used for key
derivation.

I love this editor. I only want to see it improve. I hope it does.

Me, too. I only disagree that removing this feature instead of fixing it
would be an improvement.

Someone in one of these two threads mentioned teaching cryptography at a
university level and wanting to contribute. I understand they had some
prototype code, but they were having difficulty with the swap/undo files. I
think someone should start up a branch with that code and get something
rolling for a pull request. If we do it right, once the new code is ready,
adding further new encryption methods and KDFs should be as easy as adding
a library call and a new cryptmethod value to trigger it.

@chrisbra

This comment has been minimized.

Copy link
Member

commented Aug 26, 2016

I agree. Unfortunately, I don't feel comfortable enough with crypto stuff to try to fix it. I guess we all agree, that that part should be contributed by someone, who really understands the implications. I can offer to review a patch, however.

I am also lost in those two issues, because they are rather lengthy already. Can someone summarize, what needs to be done? I think someone mentioned a library that could be used. If we outline further steps, perhaps it would be easier to get something going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.