hoi.
for quite some time i sadly didn't pay any attention to this little plugin. now i needed the ability to create good (pseudo)random characters for passwords and in the process of adding that functionality basicly rewrote the complete code. i would be very thankful if someone could test the new version for bugs and other problems. the new features are: random characters, sha3 hashes, ctr-mode for aes, new method for salting cipher keys, better&hopefully faster memory management and overall clearer code.
download: http://www.cerberus-design.de/nppcrypt/nppcryptv1008.zip
sourcecode: http://www.cerberus-design.de/nppcrypt/nppcryptv1008.src.zip
sadly there are two problems with backward compatibility to 1.007 (see also readme.txt):
1. to make the encryption more standardized i now convert passwords to utf8 instead of "default Windows ANSI" as before. this means passwords with unicode characters >=128 are not compatible with 1.007.
2. in order to make the new way of user specified salting (the old method was just useless, see faq in readme.txt) possible, i had to change the header of nppcrypt-files.
i know that testing stuff is annoying but i really would appreciate any kind of feedback.
among other things two questions would interest me:
1. notepad++ being a windows program maybe changing the passwords to utf8 isn't such a good idea after all? but shouldn't the encrypted data be universal?
2. atm after opening/saving a nppcrypt-file, i clear the undo buffer of scintilla to free up memory. is it better to let the user have the ability to "undo" the hidden encryption/decryption?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well no exactly the most active forum, but to be honest i woundn't be enthusiastic about testing some random plugin either.
Anyway i updated the new version in a way to hopefully sidestep the compatibility issues therefore rendering my own previous questions pointless. hoping that there no major bugs i will just submit it to the plugin manager
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jean!
nppCrypt plugin is awesome! Thanks!
1.008 version is not working on Windows XP SP3. On windows 7 it's all right.
I'm using Notepad++ v.6.6.7
Error message while notepad++ is starting on winXP:
"The procedure entry point EnumSystemLocalesEx could not be located in the dynamic link library KERNEL32.dll"
hi,
thanks very much for your feedback. you are quite right: i didn't know that, but as it turns out programs built with visual studio 2012 normally do not run on win xp because they use functions like the one you mentioned. luckily service pack 1 seems to have introduced the ability to target xp. it would be very nice if you could test a new nppcrypt.dll i compiled this way: http://www.cerberus-design.de/nppcrypt/xptest.zip .
ps: isn't it quite unsafe to use windows xp now that microsoft stopped to provide security-updates?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ps.
Sorry for the off topic (kind off)
about XP being unsafe, imo that's pore FUD on ms's side, seeing how they are supporting POS until 2019 (POS being XP with a new theme), most of their fixes are for ie and wmp, XP users should just use Firefox/Chrome and mpc/vlc, with a good antivirus and firewall XP can be as safe as any Win machine.
What most people don't understand is that XP machines will be around for years to come, the reason is the lack of 7 drivers for some hardware mostly graphic cards, and how most of those machines are AGP ones users can't just buy a new graphic card (there are no AGP cards with 7/8 support).
Until their mother boards, processors, graphic cards die people will keep using their old computers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for quick response! http://www.cerberus-design.de/nppcrypt/xptest.zip is working like a charm on WinXPSP3
Notepad++ starts without any errors. Encryption and decryption is also possible.
Answers to your questions from first post:
1) UTF-8 pass are better
2) In my opinion it's better now.
But I'm not sure that buffer clearing works for all scenarios:
1) Save file(encrypted)
2) Redo operation
3) See encrypted file.
Thanks again for providing patch for WindowsXP and for developing this plugin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The cryptographic concept of a "salt" is now broken in 1.008. In crypt.cpp, it is no longer prepending the salt to the encrypted stream:
// In older versions Salt was added to the front of the encrypted data.
Now, the prior release was using a static value as the "salt", which is not correct either. All this does is force a potential attacker to create two rainbow tables -- one without the fixed salt, and one with the fixed salt.
The correct approach to generate a salt is to ask the OS for some CSRNG bytes using CryptGenRandom() / RtlGenRandom() / rand_s() & use this as the salt. This salt is prepended to the output stream as well as used as part of the key derivation. This means that every time the data is encrypted, it should have a different salt. Regardless of what salt is used for a particular encryption run, it is always available during decryption.
Right now the 1.008 "salt" works as a secondary key, which is not a bad thing, but offers no additional protection for files on a local machine -- the "salt" can just be read from the nppcrypt configuration just as easily as the encrypted file. It does mean if sending nppcrypt encrypted files via email, it means that two keys are required, which you would ideally send via separate channels making it harder for an eavesdropper to obtain.
FWIW a salt does not strengthen a key -- bad keys are still bad keys. It does prevent rainbow table attacks & combinatorial attacks, so it's still of use.
Last edit: Shawn Collenburg 2014-08-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, you are of course right and i am very happy that someone knowledgeable actually looked into the source. what is rather incorrectly called "salt" works like you said rather like as a secondary key. (but i don't understand your assertion that previous versions used "static salt": they used openssls RAND_bytes the get CSRNG salt bytes before every encryption.) the idea was to make data sent via email just a little bit more secure. of course on a local machine it's useless and you lose the benefit of "real" salting. i always thought: just use a good password and you don't have to fear rainbow tables, but i realize that is probably not exactly true.
As someone who obviously knows this stuff: What do you think would be the right approach: return to actual canonical cryptographic salt, add it as an option, rename what is now called salt?
btw: if you find any other problems with the code by all means please tell me. the number of people willing or able to look at it is very very small (judgeing by downloads figures) and therefore its quite difficult to get it checked, bugs found etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hoi.
for quite some time i sadly didn't pay any attention to this little plugin. now i needed the ability to create good (pseudo)random characters for passwords and in the process of adding that functionality basicly rewrote the complete code. i would be very thankful if someone could test the new version for bugs and other problems. the new features are: random characters, sha3 hashes, ctr-mode for aes, new method for salting cipher keys, better&hopefully faster memory management and overall clearer code.
download: http://www.cerberus-design.de/nppcrypt/nppcryptv1008.zip
sourcecode: http://www.cerberus-design.de/nppcrypt/nppcryptv1008.src.zip
sadly there are two problems with backward compatibility to 1.007 (see also readme.txt):
1. to make the encryption more standardized i now convert passwords to utf8 instead of "default Windows ANSI" as before. this means passwords with unicode characters >=128 are not compatible with 1.007.
2. in order to make the new way of user specified salting (the old method was just useless, see faq in readme.txt) possible, i had to change the header of nppcrypt-files.
i know that testing stuff is annoying but i really would appreciate any kind of feedback.
among other things two questions would interest me:
1. notepad++ being a windows program maybe changing the passwords to utf8 isn't such a good idea after all? but shouldn't the encrypted data be universal?
2. atm after opening/saving a nppcrypt-file, i clear the undo buffer of scintilla to free up memory. is it better to let the user have the ability to "undo" the hidden encryption/decryption?
well no exactly the most active forum, but to be honest i woundn't be enthusiastic about testing some random plugin either.
Anyway i updated the new version in a way to hopefully sidestep the compatibility issues therefore rendering my own previous questions pointless. hoping that there no major bugs i will just submit it to the plugin manager
Or nppcrypt v1.008 works under Windows XP SP3??
well, i don't know. doesn't it? i don't use win xp anymore (and neither should you ^^). [please use the latest notepad++ version].
Hi Jean!
nppCrypt plugin is awesome! Thanks!
1.008 version is not working on Windows XP SP3. On windows 7 it's all right.
I'm using Notepad++ v.6.6.7
Error message while notepad++ is starting on winXP:
"The procedure entry point EnumSystemLocalesEx could not be located in the dynamic link library KERNEL32.dll"
After some digging:
Cite:
EnumSystemLocalesEx function
"The application should call this function in preference to EnumSystemLocales if designed to run only on Windows Vista and later."
http://msdn.microsoft.com/en-us/library/windows/desktop/dd317829%28v=vs.85%29.aspx
Is it possible to use EnumSystemLocales function instead of EnumSystemLocalesEx in your plugin?
hi,
thanks very much for your feedback. you are quite right: i didn't know that, but as it turns out programs built with visual studio 2012 normally do not run on win xp because they use functions like the one you mentioned. luckily service pack 1 seems to have introduced the ability to target xp. it would be very nice if you could test a new nppcrypt.dll i compiled this way: http://www.cerberus-design.de/nppcrypt/xptest.zip .
ps: isn't it quite unsafe to use windows xp now that microsoft stopped to provide security-updates?
hi
http://www.cerberus-design.de/nppcrypt/xptest.zip
Works fine under XP-SP3
ps.
Sorry for the off topic (kind off)
about XP being unsafe, imo that's pore FUD on ms's side, seeing how they are supporting POS until 2019 (POS being XP with a new theme), most of their fixes are for ie and wmp, XP users should just use Firefox/Chrome and mpc/vlc, with a good antivirus and firewall XP can be as safe as any Win machine.
What most people don't understand is that XP machines will be around for years to come, the reason is the lack of 7 drivers for some hardware mostly graphic cards, and how most of those machines are AGP ones users can't just buy a new graphic card (there are no AGP cards with 7/8 support).
Until their mother boards, processors, graphic cards die people will keep using their old computers.
Thank you for quick response!
http://www.cerberus-design.de/nppcrypt/xptest.zip is working like a charm on WinXPSP3
Notepad++ starts without any errors. Encryption and decryption is also possible.
Answers to your questions from first post:
1) UTF-8 pass are better
2) In my opinion it's better now.
But I'm not sure that buffer clearing works for all scenarios:
1) Save file(encrypted)
2) Redo operation
3) See encrypted file.
Thanks again for providing patch for WindowsXP and for developing this plugin.
The cryptographic concept of a "salt" is now broken in 1.008. In crypt.cpp, it is no longer prepending the salt to the encrypted stream:
// In older versions Salt was added to the front of the encrypted data.Now, the prior release was using a static value as the "salt", which is not correct either. All this does is force a potential attacker to create two rainbow tables -- one without the fixed salt, and one with the fixed salt.
The correct approach to generate a salt is to ask the OS for some CSRNG bytes using CryptGenRandom() / RtlGenRandom() / rand_s() & use this as the salt. This salt is prepended to the output stream as well as used as part of the key derivation. This means that every time the data is encrypted, it should have a different salt. Regardless of what salt is used for a particular encryption run, it is always available during decryption.
Right now the 1.008 "salt" works as a secondary key, which is not a bad thing, but offers no additional protection for files on a local machine -- the "salt" can just be read from the nppcrypt configuration just as easily as the encrypted file. It does mean if sending nppcrypt encrypted files via email, it means that two keys are required, which you would ideally send via separate channels making it harder for an eavesdropper to obtain.
FWIW a salt does not strengthen a key -- bad keys are still bad keys. It does prevent rainbow table attacks & combinatorial attacks, so it's still of use.
Last edit: Shawn Collenburg 2014-08-03
well, you are of course right and i am very happy that someone knowledgeable actually looked into the source. what is rather incorrectly called "salt" works like you said rather like as a secondary key. (but i don't understand your assertion that previous versions used "static salt": they used openssls RAND_bytes the get CSRNG salt bytes before every encryption.) the idea was to make data sent via email just a little bit more secure. of course on a local machine it's useless and you lose the benefit of "real" salting. i always thought: just use a good password and you don't have to fear rainbow tables, but i realize that is probably not exactly true.
As someone who obviously knows this stuff: What do you think would be the right approach: return to actual canonical cryptographic salt, add it as an option, rename what is now called salt?
btw: if you find any other problems with the code by all means please tell me. the number of people willing or able to look at it is very very small (judgeing by downloads figures) and therefore its quite difficult to get it checked, bugs found etc.
Arrgh. SourceForge ate my comment, so here's the short version:
I recommend added a cryptographic salt to 008. Rename the current "salt" as "Secondary password".
I saw no other issues when I did a quick browse of the code. I will try to do a more detailed review this weekend.