Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I recently began using Vim to encrypt text files (by using the :X command and entering an encryption key at the prompt). As documented, Vim then prompts for that key when I reopen the file and decrypts the text.

Today, I opened one of those encrypted files, but to my surprise Vim did not prompt me for any key and simply displayed encrypted text. I of course reopened the file several more times, but always with the same result. (I am using Vim 7.3 on OS X. I found no difference in behavior in MacVim vs. the non-GUI version.)

I have three vague hunches as to what could be causing this problem:

  1. I had renamed the file in question—possibly more than once—after it was encrypted. Unfortunately, I can't actually remember if I had ever decrypted the file successfully since the latest rename.
  2. This file is stored in my Dropbox folder, so if the file was changed somehow on the Dropbox server, that version presumably would have overwritten my (previously good) local version. (However, when I try to recover an old version of the file via Dropbox, I only find a single version of the file, and I can't decrypt that either.)
  3. Combining the above two: I actually renamed the file so that it has a .crypt extension, not thinking this would matter locally, but I see that Dropbox is actually identifying this file (in the Kind column) as file crypt. Perhaps Dropbox handled that file differently in some way if it recognized it as an encrypted file? (However, when I store an unencrypted text file with extension .crypt, I don't experience any trouble reading it.)

I tried to use openssl to recover the file, specifically as openssl bf -d -in [encrypted file] -out [decrypted file]. But this reports bad decrypt 1948:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/evp/evp_enc.c:330: (or slight variations).

(Let me preemptively make clear that I am 99% sure this isn't a case of me using the wrong encryption key, as I had successfully decrypted the file numerous times in the past, and now Vim isn't even prompting for a key. I've also double-checked that I'm using the right key with openssl.)

I used Vim's default encryption, which I understand to be blowfish in 7.3 (although I tried a few other cipher commands with openssl but wasn't sure which, if any, corresponded to pkzip, which I understand to be Vim's older encryption algorithm.)

I found nothing of relevance in :help encryption except to try to use :set key= to ensure Vim prompts me for a key for encrypted files, but it still doesn't. This was the only solution suggested in somewhat similar questions I found elsewhere (e.g., this question, although typing the key sans prompt in my case is simply interpreted as commands starting in normal mode).

Finally, it may be of some use to know that the beginning of the file in question (before all the encryption garbage) is "Salted"; if Vim has salted the encryption key, could the salt somehow go missing (in, ahem, layman's terms)?

Just to be clear, my primary questions are:

  1. What is causing Vim to no longer see the file as encrypted and in need of a decryption key? Even if I can't recover the text, I'd like to be able to avoid this in the future if possible. For example, is synching an encrypted file with Dropbox a big no-no?
  2. Is there anything else I might try to recover the text? Even brute-forcing seems out of the question since it's not a missing-key issue, but perhaps I'm misusing openssl or ignoring another Vim solution.

Thanks!

———

EDIT: I have noticed something else that may be relevant. I tried to replicate this problem, and in the course of that I've noticed that with a "good" encrypted Vim file (i.e., one I can decrypt successfully), if I use Quick Look to view the file or if I open it in TextEdit, I only see a single line of text that reads something like VimCrypt~01!9‰◊ëMå Ø^efl.œ1b_öä˙ß≥. But when I open the file I'm having trouble with, I instead get 130 lines of apparent ciphertext, with the first line beginning with Salted (as mentioned above).

share|improve this question
1  
Could you please share any related settings that you have in your .vimrc file? Does this happen only with one file, or with every file? –  Greduan Jan 7 '13 at 15:39
    
I'm not sure what in my .vimrc could affect this; the only things that I can imagine altering the file that I have set are autoread,smarttab,autoindent,wrap, and showbreak. –  Andy Mo Jan 7 '13 at 18:02
1  
I can't seem to replicate this, either. I created another file, encrypted it, decrypted successfully, renamed it, decrypted successfully, moved to Dropbox, and decrypted successfully again. One thing I did notice is that when I changed the extension to *.crypt in Finder, a hidden *.txt extension was still appended, and OSX still showed the "TXT" file icon. But even after I eliminate that *.txt extension with Terminal I still can decrypt successfully. –  Andy Mo Jan 7 '13 at 18:05
1  
Hmm, make sure that Finder stops hiding these file extensions (in it's settings). Well, do lots of tests in lots of cases. Try renaming the file as well, etc. See if you can find the cause of it. Also, those settings you showed don't really affect that. :) –  Greduan Jan 7 '13 at 18:14
1  
After years of forcing OS X to show extensions I apparently lapsed, so that setting is back on, at least! Good suggestions about test cases. –  Andy Mo Jan 7 '13 at 21:19

1 Answer 1

up vote 4 down vote accepted

I'm going to address sections of your query out of order, hopefully it won't be confusing.

From your edit, it appears to me that your file is corrupted beyond Vim's being able to open it. All files encrypted with Vim's internal encryption should start with "VimCrypt~N" where "N" is a number (currently only 01 and 02 are supported). That your file starts with "Salted" is confusing, but confirms that Vim will not recognize the file as a Vim encrypted file.

Moving or renaming the file should not affect Vim's ability to recognize it as encrypted and as long as you continue to use the correct key, it should decrypt without problem. Filename extension should similarly be meaningless to Vim since it looks at the file contents to determine if it is a Vim encrypted file.

I also keep one of my Vim encrypted files in Dropbox and I have not had issues with it becoming corrupted.

You mentioned that you believe that Blowfish is Vim's default encryption scheme. This is not the case. The default is zip which is "cheap and fast" and also (probably) breakable. It is also the first encryption method Vim supported which is why it became the de-facto default. If you want to default to Blowfish you need to put the following in your vimrc:

:set cryptmethod=blowfish

You can actually determine which was used on a file without opening it in Vim by opening the file in a pager or other editor (or even by opening it in Vim and not entering a key) and looking at the above mentioned header-prefix text. If it says "VimCrypt~01" it is the zip method. If it says "VimCrypt~02" it uses the stronger Blowfish method. (You'll note that the header example you posted in your edit shows "01".)

You should also be able to determine which method is used if you are currently editing the decrypted file by typing ":set cryptmethod?" (the question mark is part of the command).

share|improve this answer
1  
Thanks for all the good information, even if it confirms my fears about the file! Actually, I thought that pkzip was the default encryption method and tried to use openssl for that, but something I read while researching this made me think Vim had <em>changed</em> the default to blowfish in 7.3 rather than just adding it. My mistake. –  Andy Mo Jan 7 '13 at 21:40
    
Bram Moolenaar, the owner and main developer of Vim, really dislikes changing defaults once they're established. I think in this case he should have, as I doubt it would have broken anything. –  Heptite Jan 8 '13 at 5:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.