On Sun, Feb 17, 2013 at 6:55 AM, Ulrik <[email protected]> wrote: > On 2013-02-16 18:16, Bram Moolenaar wrote: >> >> Ulrik Sverdrup wrote: >> >>>>> The blowfish encryption mode is vulnerable (not to revelation of the >>>>> plaintext), but the encryption is not checked for integrity or >>>>> authenticity. This means that someone might corrupt the encrypted file >>>>> (hexedit or similar), and vim will decrypt it without notice of error or >>>>> warning. >>>>> >>>>> This attack allows someone to modfiy encrypted files so that the owner >>>>> doesn't notice. With sufficient tries or skill it might be possible to >>>>> change a file's values in a predictable way at a certain offset. >>>>> >>>>> The solution is an authenticated encryption mode. The common way to do >>>>> it is 'Encrypt-then-MAC' where a message authentication code is formed >>>>> from the ciphertext and the key. This code when matching will prove that >>>>> the document is unchanged and was produced by someone with access to the >>>>> key. This code will detect the previous attack case, and additionally it >>>>> allows vim to detect that the wrong password was entered. Security >>>>> practise says that Vim must fail with an error if the MAC does not match. >>>> >>>> I think that a verification key will actually make it easier to crack >>>> the password. Currently, when an attacker tries all kinds of passwords, >>>> he also needs a way to verify the decrypted text is actually readable. >>>> That is not so easy to do. With a verification key the verify part >>>> becomes really easy and fast. >>>> >>>> It is extremely difficult to change the file in a way that after >>>> decryption it is readable text. Probably just as difficult as cracking >>>> the password. When knowing that a file is only plain text, checking for >>>> invalid Unicode characters is probably sufficient to notice that the >>>> decryption failed. >>>> >>> >>> Using Vim 7.3 patches 1-547, this is not true, and it is trivially >>> testable (otherwise I would not have claimed it). >>> >>> Using :set cm=blowfish :X goodenough >>> I produced file A that ends with "I owe you 200 USD" >>> >>> using hex editor I flipped 1 single bit to produce file B, that ends >>> with "I owe you 300 USD". You can diff the two binary files by using: >>> >>> diff <(xxd A) <(xxd B) >>> >>> a one-bit difference in the ciphertext leads to a one-bit difference in >>> the plain text, and we have a false document and undedetected corruption. >>> >>> To reproduce, here are files A and B: >>> >>> xxd -r >A <<EOF >>> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780 VimCrypt~02!F8.. >>> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7 3*...... ..y..l. >>> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba .C....j.......$. >>> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad ......l..C....j. >>> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7 ......$.......l. >>> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f .C....j......... >>> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c #"....Y.G...Zb.. >>> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1 ...$....#"....Y. >>> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f G...Zb.....$.... >>> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56 #"....x.[..L..mV >>> 00000a0: 32e5 962e b15c 000a f6 2....\... >>> EOF >>> >>> xxd -r >B <<EOF >>> 0000000: 5669 6d43 7279 7074 7e30 3221 4638 a780 VimCrypt~02!F8.. >>> 0000010: 332a 14a3 e680 d2dd 2003 d079 9b8a 6ca7 3*...... ..y..l. >>> 0000020: 0e43 da8b b1bb 6aad 0f1a c38c f4ba 24ba .C....j.......$. >>> 0000030: 181b c7d6 9b8a 6ca7 0e43 da8b b1bb 6aad ......l..C....j. >>> 0000040: 0f1a c38c f4ba 24ba 181b c7d6 9b8a 6ca7 ......$.......l. >>> 0000050: 0e43 da8b b1bb 6aad 0f1a c38c ec09 c98f .C....j......... >>> 0000060: 2322 0fd6 1aff 59b1 47cc a61f 5a62 c89c #"....Y.G...Zb.. >>> 0000070: eba3 d824 ec09 c98f 2322 0fd6 1aff 59b1 ...$....#"....Y. >>> 0000080: 47cc a61f 5a62 c89c eba3 d824 ec09 c98f G...Zb.....$.... >>> 0000090: 2322 0fd6 1aa1 78f8 5b9b aa4c dbfb 6d56 #"....x.[..L..mV >>> 00000a0: 33e5 962e b15c 000a f6 3....\... >>> EOF >>> >>> >>> Note: I didn't search or brute force this, I only counted the right byte >>> offset in the file and flipped a bit. I really hope I am somehow >>> mistaken, but I don't think I am. >>> >>> Regarding quickening brute force by using a MAC, this is a false, the >>> MAC can have equivalent security factor to the block cipher, it should >>> really not be a concern. >> >> You could only make this change because you have seen the readable text. >> Without that you had no clue what bits to change to get any desired >> effect. Exactly the same thing could have been done on the unencrypted >> text, but then obviously it is possible to change what you desire. >> However, the encryption does not have to goal of making these changes >> impossible or even difficult. >> >> The whole point of the encryption is to make the text unreadable. It is >> not a signature of any kind. Signing files, encrypted or not, is a >> totally different thing and there are plenty of tools for that. >> > > The type of the attack is that if you XOR a value with the ciphertext, > the same XOR difference shows in the decrypted text. Knowing a small > part of the plaintext is not a big requirement on an attack as simple as > this one. > > I understand that Vim only wants to provide confidentiality, not > integrity, but taken together with the usability issue of not giving > notice of a wrong password, I don't understand the choice. I don't enjoy > the possibility given that I might absent-mindedly type :w when getting > the garbage output after a mistyped password, destroying my data.
Yes, this is a problem. > (The only reason I bring these up together is that a MAC would allow Vim > to easily detect if the password is correct.) It is easy to save the checksum (1 or 2 byte of the final iv into the header), so we could check for errors after decrypting, but this will bump up the version number of vimcrypt to ~03. > > The frontiers for encryption have changed during the internet era and > since Blowfish was published (1994). Current best practices give the > users much more safety. View it as a development history where > accumulated patches have created a more reliable product, if you want. > Vim entering the "strong encryption" field, with Vim 7.3, in this way is > unfortunate, because it looks more like the solutions date from the 1990's. > > Best Regards, > -ulrik > > -- > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
