Mr. Fritz wrote:
> It seems to be related to encrypting the swapfile for the new file.
Hooray! Problem solved! Acute observation.
I tested again for many times and am sure the issue lies in the swapfile's creation and/or encryption. Before this issue is fixed, we have to use:
gvim -n file_to_encrypt_or_decrypt
to properly encrypt and decrypt.
Also, we could dirctedly open a file to encrypt and use:
:set noswapfile
to get rid of swapfile, and every thing goes fine.
Note that, when we decrypt a file, we have to use command line: gvim -n file because vim will immediately prompt for password thus give no chance to use ':set noswapfile' for correct decryption.
Mr. Moolenaar wrote:
> Since it works fine on Linux...It's a common problem for porting a C program to Windows.
It is so easy to make mistakes in a twisted OS.
Mr. Fritz wrote:
> The strength of the cryptography does NOT come from not knowing the encryption method. It comes from the fact that the encryption method itself is not breakable.
> Hiding the fact that it's using OpenSSL, or hiding the size of the key in use, doesn't make a website more secure.
> Hiding the magic string does nothing at all to enhance security.
I agree with you that blowfish algorithm is secure. But at the same time, it requires an ENOUGH LONG password for the encrypted file to be enough safe. What I mean is more encryption methods in Vim could FURTHER GREATLY enhance security.
The prerequisite for a cracker to decrypt is he knows the encryption method by which a file is encrypted. Without knowing the encryption method at first, how would he decrypt? Say, one uses CAST5 to encrypt a file. If the cracker doesn't know the method and uses blowfish to brute-force decrypt, he will never succeed. The cracker will think that the password must be very long and he will continue to try and try. This way, hiding the encryption method certainly help enhance security. But for now, vim has only one strong encryption method and leaving out magic string makes no sense if the cracker could guess file is created with vim. It seems that you are suggesting the encryption method like blowfish or CAST5 can be found from encrypted file maybe because there are some encryption method specific patterns in that messed file. If this is the case, you are right and hiding the encryption method has no meaning. But is it really possbile to find the encryption method from an encryptedly messed file(except weak methods like zip encrypted file. I mean strong ones like blowfish.)? If the answer is no, then encrypting with one strong method an encrypted file that has already been encryted with another strong one will OF COURSE make sense as the attacker will never know that cracked file is another encrypted file or a real mess, and we can eliminate attackers analysing the text after decryption to see if it looks like words.
The reason OpenSSL is generally considered secure is because the key is ENOUGH LONG or difficult factorization, which makes the brute-force decryption too long time. But that kind of security never means more encryption methods accompanied with hiding the encryption mothod will not GREATLY enhance data security.
Best wishes,
Tora (Tiger in Japanese)
> It seems to be related to encrypting the swapfile for the new file.
Hooray! Problem solved! Acute observation.
I tested again for many times and am sure the issue lies in the swapfile's creation and/or encryption. Before this issue is fixed, we have to use:
gvim -n file_to_encrypt_or_decrypt
to properly encrypt and decrypt.
Also, we could dirctedly open a file to encrypt and use:
:set noswapfile
to get rid of swapfile, and every thing goes fine.
Note that, when we decrypt a file, we have to use command line: gvim -n file because vim will immediately prompt for password thus give no chance to use ':set noswapfile' for correct decryption.
Mr. Moolenaar wrote:
> Since it works fine on Linux...It's a common problem for porting a C program to Windows.
It is so easy to make mistakes in a twisted OS.
Mr. Fritz wrote:
> The strength of the cryptography does NOT come from not knowing the encryption method. It comes from the fact that the encryption method itself is not breakable.
> Hiding the fact that it's using OpenSSL, or hiding the size of the key in use, doesn't make a website more secure.
> Hiding the magic string does nothing at all to enhance security.
I agree with you that blowfish algorithm is secure. But at the same time, it requires an ENOUGH LONG password for the encrypted file to be enough safe. What I mean is more encryption methods in Vim could FURTHER GREATLY enhance security.
The prerequisite for a cracker to decrypt is he knows the encryption method by which a file is encrypted. Without knowing the encryption method at first, how would he decrypt? Say, one uses CAST5 to encrypt a file. If the cracker doesn't know the method and uses blowfish to brute-force decrypt, he will never succeed. The cracker will think that the password must be very long and he will continue to try and try. This way, hiding the encryption method certainly help enhance security. But for now, vim has only one strong encryption method and leaving out magic string makes no sense if the cracker could guess file is created with vim. It seems that you are suggesting the encryption method like blowfish or CAST5 can be found from encrypted file maybe because there are some encryption method specific patterns in that messed file. If this is the case, you are right and hiding the encryption method has no meaning. But is it really possbile to find the encryption method from an encryptedly messed file(except weak methods like zip encrypted file. I mean strong ones like blowfish.)? If the answer is no, then encrypting with one strong method an encrypted file that has already been encryted with another strong one will OF COURSE make sense as the attacker will never know that cracked file is another encrypted file or a real mess, and we can eliminate attackers analysing the text after decryption to see if it looks like words.
The reason OpenSSL is generally considered secure is because the key is ENOUGH LONG or difficult factorization, which makes the brute-force decryption too long time. But that kind of security never means more encryption methods accompanied with hiding the encryption mothod will not GREATLY enhance data security.
Best wishes,
Tora (Tiger in Japanese)
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment