Re: improving encryption in vim
Nicolas Weber wrote: To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption isn't vim exported from the Netherlands? Right, the main ftp server is in the Netherlands. All the rest are (cached) copies. I'm not a lawyer, but I would say that this means that the code isn't exported from the USA. It was already outside. I'm not sure about the CVS server at SourceForge. Generally I don't really care about these stupid US rules. The actual result is not that access to strong encryption by non-US contries decreases but that the development is done outside of the US, with the effect that knowledge outside of the US grows. -- TIM:Too late. ARTHUR: What? TIM:There he is! [They all turn,, and see a large white RABBIT lollop a few yards out of the cave. Accompanied by terrifying chord and jarring metallic monster noise.] Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: improving encryption in vim
On Mon, 19 Mar 2007 09:22:08 -0600, Josh [EMAIL PROTECTED] wrote: There are no patent issues, but there is export issues, I live in the US The reason I suggested Rijndael is because there are no US export issues. Not only was it developed in Flanders so implementations outside the US abound, but also as Rijndael was the winning AES candidate the export of Rijndael implementations from the US is explicitly permitted. See the final paragraph of http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html -- Matthew Winn
Re: improving encryption in vim
Matthew Winn wrote: On Mon, 19 Mar 2007 09:22:08 -0600, Josh [EMAIL PROTECTED] wrote: There are no patent issues, but there is export issues, I live in the US The reason I suggested Rijndael is because there are no US export issues. Not only was it developed in Flanders so implementations outside the US abound, but also as Rijndael was the winning AES candidate the export of Rijndael implementations from the US is explicitly permitted. See the final paragraph of http://csrc.nist.gov/CryptoToolkit/aes/aesfact.html To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption (64-bit symmetric keys, other limits for public-key/elliptic algorithms), then it _is_ subject to export restrictions. As the linked page says, it is exportable, but subject to a one-time review prior to export. It doesn't matter if all it does is call a subroutine that was developed in another country or even if the library itself was subjected to review and approval (e.g. see Legal Notices at http://aescrypt.sourceforge.net/). The regulations are at http://www.bis.doc.gov/encryption/Default.htm However, starting in June, 2002, the notification for Publicly Available Encryption Source Code (open-source) is very simple, just submitting the URL. See http://www.bis.doc.gov/encryption/PubAvailEncSourceCodeNofify.html But, on the other hand, the code is not supposed to be exported to certain countries. Mozilla says (currently Cuba, Iran, Libya, North Korea, Sudan and Syria) (http://www.mozilla.org/projects/security/pki/src/download.html). See also http://www.mozilla.org/crypto-faq.html Including AES in vim might require that mirror servers in the U.S. set up IP range blocking for these countries. I don't know, I am not a lawyer. Note that I am not arguing that the export regulations make sense or are effective! Blowfish is only 56 bits, so it is not subject to export regulations. It is probably unbreakable to anyone except the NSA or the equivalent in resourceful foreign countries. (That is, if you choose your keys well.) A determined attacker _might_ be able to break it, but there are usually simpler ways of getting information (malware, hardware key loggers, etc.). If you don't think that Blowfish is sufficient, please explain why and specify what kind of threat you are trying to protect against. Ken Hirsch P.S. It's also really easy to use external commands for encryption. See gnupg.vim at http://www.vim.org/scripts/script.php?script_id=661 Or, if you have OpenSSL installed, you could do something like this: :augroup aes256 : autocmd! : autocmd BufReadPre,FileReadPre*.aes set bin : autocmd BufReadPost,FileReadPost*.aes '[,']!openssl enc -d -aes-256-cbc : autocmd BufReadPost,FileReadPost*.aes set nobin : autocmd BufReadPost,FileReadPost*.aes execute :doautocmd BufReadPost . expand(%:r) : autocmd BufWritePost,FileWritePost*.aes !mv afile afile:r : autocmd BufWritePost,FileWritePost*.aes !openssl enc -e -aes-256-cbc -in afile:r -out afile : autocmd FileAppendPre*.aes !openssl enc -d -aes-256-cbc -in afile -out afile:r : autocmd FileAppendPre*.aes !mv afile:r afile : autocmd FileAppendPost*.aes !mv afile afile:r : autocmd FileAppendPost*.aes !openssl enc -e -aes-256-cbc -in afile:r -out afile :augroup END
Re: improving encryption in vim
On Sun, Mar 18, 2007 at 08:55:33PM +0100, Bram Moolenaar wrote: Main issue is that the current encryption is breakable. We need a stronger encryption, which is free to distribute. We only need one new method. If a strong encryption algorithm is used, the keys may still be the weak spot. A plain assword will be breakable, but it is convenient and probably good enough in many cases. However, if it should be possible to use for business secrets it may be necessary to allow for the key to be stored in a separate file. I see no reason to choose anything else than AES (FIPS-197, Rijandel). It's probably the most well analyzed block cipher today. I don't think it makes any sense to choose a breakable algorithm just to avoid export restrictions, then it would be just as good to keep the current methods instead. It seems better to make sure that the code is developed in a country with sensible export laws, and not reexported from any country with unreasonable laws. Someone mentioned padding - all block ciphers operate on blocks of data, but the mode of operation used determines whether padding is needed or not: http://csrc.nist.gov/CryptoToolkit/modes/ Blowfish was mentioned. It does not use 56 bit keys but it can use up to 448 bits (56 bytes). It uses 64 bit blocks. I don't think there are any known weakness, but I think AES is a better choice (it uses 128, 192 or 256 bit keys and a block size of 128 bits). But as I mentioned, the difficult thing will be to come up with a good way to handle keys. It may also be a good idea to use some integrity check. Andreas
Re: improving encryption in vim
Hi, To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption isn't vim exported from the Netherlands? Nico
Re: improving encryption in vim
Ken Hirsch wrote: [...] To clarify, based on my understanding: if software is exported from the U.S., which vim arguably is, and it is capable of powerful encryption (64-bit symmetric keys, other limits for public-key/elliptic algorithms), then it _is_ subject to export restrictions. As the linked page says, it is exportable, but subject to a one-time review prior to export. It doesn't matter if all it does is call a subroutine that was developed in another country or even if the library itself was subjected to review and approval (e.g. see Legal Notices at http://aescrypt.sourceforge.net/). The regulations are at http://www.bis.doc.gov/encryption/Default.htm [...] Vim is exported from the Netherlands, not the US. Bram is a Dutch national, now living in Zurich (Switzerland) but during most of the time in which he developed Vim, he lived in Venlo (The Netherlands). The Vim ftp servers are hosted by ftp.nluug.nl (a server in the Netherlands). Best regards, Tony. -- Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- H. L. Mencken
Re: improving encryption in vim
On Sun, 18 Mar 2007 15:57:33 -0600, Josh [EMAIL PROTECTED] wrote: The main problem that I see is that adding a strong encryption function can have regulation issues. That was the only reason that I thought about using the external library is to get around this. With an algorithm like Rijndael there are no patent issues (and there is even unencumbered public source code available), and the only problem is with countries that forbid the use of encryption software. I imagine that can be solved in the same way as other conditional compilation matters are tacked in Vim: putting the code in a separate file and using a compile-time option to include it where available. How secure does the encryption need to be? Considering that Rijndael offers 128-bit, 192-bit and 256-bit security with very fast and simple code, it's more a matter of: why would you bother with anything less than the best encryption you can get? -- Matthew Winn
Re: improving encryption in vim
Josh wrote: Another idea that I saw on the list was improving the encryption in vim and encrypting the swap file. The ideas that I have for this range from replacing the encryption function in vim with one that is more secure to adding support for an external library library to adding functions to modify the encryption support in the various scripting languages that vim has. Am i missing any details? Main issue is that the current encryption is breakable. We need a stronger encryption, which is free to distribute. We only need one new method. Using an external library creates an extra dependency. It would be easier to select an algorithm which we can include directly. That also means the code for it must be relatively short. Encrypting the swap file is actually another item, although it's related. Goal is that the harddisk doesn't contain plain text. Although virtual memory page swapping may still write something to disk (most systems don't allow disabling this). -- The early bird gets the worm. If you want something else for breakfast, get up later. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
