Interesting article thanks for mentioning it. I didn't find it very
encouraging though...
So I don't know the answer to your question exactly. But it got me curious
too. I had a look in the code. There are two places that parse the command
line: src/ui/Windows/ThisMfcApp.cpp and src/ui/wxWidgets/pwsafeapp.cpp.
Comparing the code in these two file to the help document
help/default/html/cli.html, I see only two extra command line arguments,
both in the MFC (Windows only) code: --fix-utf8 and --setup. Both of these
options appear to me to be doing what the code comments say they are there
for. The --fix-utf8 fixes reading databases created with an older version
that had non-English text in them. The --setup flag is used to create a
clean DB following an fresh install.
I wonder if he is using a 'special' version that contains code we do not
have? But then again he's a lot smarter than I am so there could be an
option that I can't see but it's right in front of me.
So that explains the recent rise in downloads (& donations) from the UK...
I guess I'll have to document the '-e/-d' flags now. Truth is, I wanted to deprecate this, as it's not really in line with the main purpose of PasswordSafe, but now that the feature's "officially undocumented", I guess it will have to stay.
--setup is used when PasswordSafe's run from the installer, and --fix-utf8 was written for a friend who started using PasswordSafe in a foreign language before I got the bugs out of UTF-8 support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks to me like -e and -d are well documented in the help file under Using Password Safe/Command Line Arguments.
Perhaps a nice addition would be a Windows Explorer context menu item to execute those commands on selected files for those of us who like to stay out of the Command Line weeds. Of course, as you said, Rony, that digresses from the main purpose of Password Safe. Still, if the capability exists, then . . . ?
(There are many other alternatives to encrypting/decrypting files on the disk; for example, the free AxCrypt which uses AES-256 and the $29 WinRar which uses AES-128, both of which can create a self-extracting file.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There was no "AES" at the time of Schneier's Password Safe.
Rijndael*, developed by Rijmen and Daemen - two EU cryptographers, was selected by NIST as the AES cipher at or about 2001.11. Six months later it was approved by US Gov/NSA.
PwSafe uses Twofish
*Rijndael 128-bit block
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
See below and attached file for example method
to create Right-Click Explorer context menu items
"Encrypt File with PasswordSafe",
"Decrypt File with PasswordSafe".
Adjust path to executable as necessary.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\PwSafe_1_Encrypt_File]@="Encrypt File with PasswordSafe"[HKEY_CLASSES_ROOT\*\shell\PwSafe_1_Encrypt_File\command]@="cmd /c c:\\\"program files\"\\pwsafe\\pwsafe.exe -e \"%1\""[HKEY_CLASSES_ROOT\*\shell\PwSafe_2_Decrypt_File]@="Decrypt File with PasswordSafe"[HKEY_CLASSES_ROOT\*\shell\PwSafe_2_Decrypt_File\command]@="cmd /c c:\\\"program files\"\\pwsafe\\pwsafe.exe -d \"%1\""
I couldn't get it to work quite right the way you wrote it, but taking the "cmd" out and moving the quotation marks fixed it for me. This is how I changed registry entries 2 and 4 (as you said, the path needs to be adjusted to where Password Safe is installed):
Good you've got a working solution.
Better without superfluous command prompt.
If you are using Windows 7 you may have interest in mimicking a shell extention
with a cascading flyout menu:
I thought to chime in with some clarifications re prior posts in this thread:
1. B. Schneier did refer to the -e command, as he clarified in a subsequent blog entry.
2. AxCrypt uses AES-128 . WinRAR had used AES-128 up until the recent V.5, where this was changed to AES-256
3. The -e command, as opposed to AxCrypt, can not process large files. See https://sourceforge.net/p/passwordsafe/feature-requests/702/
4. People who wish to use the -e/-d switch but do not want to deal with the registry can simplify the command prompt management by doing the following:
a. make sure the PWSafe is in the environment path
b. In Windows Explorer, where the file to be processed is listed, use SHIFT+RightClick (when nothing is selected) and in the pop-up menu you will have a new entry "open windows command here" (tested in WIN7). This will save you from dealing with folder navigation from the command prompt., letting you use the PWSafe in command mode where you are.
Last edit: Kob 2013-09-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A bit more:
PWSafe up until V.3 (IIRC) used Blowfish, Since V.3 it has been using Twofish. I prefer either one over AES not because AES might have a backdoor(*), but because if somehow the NSA would put up the resources to crack a well-established encryption algorithm, AES would be the first choice due to its ubiquity. Regardless, in practical terms it is much more efficient to attack the implementation than the core algorithm, and open-source is not panacea - have any of you gone through every line of PWSafe to verify that there are no unexplained lines before personally compile it for his/her usage?
(*)the AES algorithm is well established, done by European researchers before the Patriot Act, easy to make sure that it has no "funny" constants like the recent EC RNG case, and one can compare the code and the encryption results to any published AES algorithm gathered from any of the many different sources for the last 12 years.
Last edit: Kob 2013-09-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know if I failed to copy the registry information above correctly but I could not make those registry keys work. On Win 7 Pro 64 bit the values that ended up working for me are:
[HKEY_CLASSES_ROOT*\shell\PwSafe_1_Encrypt_File]
@="Encrypt File with PasswordSafe"
To use these, copy them to a text file, save it with a .reg extension and then import to the registry. All the usual scary warnings regarding the dangers of editing the registry still apply.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just noted something odd with the registry information I pasted in above and I don't know if this is related to the problem I had using the original suggestions. Some of the strings do not appear as entered, and that makes me suspect that either Firefox or the forum software are treating some of the back slashes as special characters in the text box.
There SHOULD be a \ character before the * character in each of the registry keys above, and the paths to the Password Safe program entry SHOULD have double back slashes between folder names if this is to be used as a registry file import.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. Did you try what I posted earlier for 64-bit Windows (although it was just a piecemeal comment to Fernando's post)? "cmd /c" didn't seem to be necessary. Here's the reg file I exported which has been working fine in Windows 8 Pro. If it's not working properly after importing, check to make sure that the two command values are:
I'm not sure I tried yours correctly, I don't recall exactly how I edited in to the original .reg file suggestion, but I was not able to make it work. In fact, I was not able to make any of the versions that put the %1 into quotes work.
I guess since the registry keys as they appear in my post are not correct I should post the registry file I exported from regedit after I got everything set up correctly.
Does anyone know what Bruce Schneier is referring to in this article? http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
"There's an undocumented encryption feature in my Password Safe program from the command line); I've been using that as well."
Interesting article thanks for mentioning it. I didn't find it very
encouraging though...
So I don't know the answer to your question exactly. But it got me curious
too. I had a look in the code. There are two places that parse the command
line: src/ui/Windows/ThisMfcApp.cpp and src/ui/wxWidgets/pwsafeapp.cpp.
Comparing the code in these two file to the help document
help/default/html/cli.html, I see only two extra command line arguments,
both in the MFC (Windows only) code: --fix-utf8 and --setup. Both of these
options appear to me to be doing what the code comments say they are there
for. The --fix-utf8 fixes reading databases created with an older version
that had non-English text in them. The --setup flag is used to create a
clean DB following an fresh install.
I wonder if he is using a 'special' version that contains code we do not
have? But then again he's a lot smarter than I am so there could be an
option that I can't see but it's right in front of me.
HTH, Mark
--
Mark Clayton
www.mark-clayton.com
On Fri, Sep 6, 2013 at 12:37 PM, Mick Mickle mickmickle@users.sf.netwrote:
that could be the "[-e|-d] filename" option to encrypt/decrypt a file for transfering it?
So that explains the recent rise in downloads (& donations) from the UK...
I guess I'll have to document the '-e/-d' flags now. Truth is, I wanted to deprecate this, as it's not really in line with the main purpose of PasswordSafe, but now that the feature's "officially undocumented", I guess it will have to stay.
--setup is used when PasswordSafe's run from the installer, and --fix-utf8 was written for a friend who started using PasswordSafe in a foreign language before I got the bugs out of UTF-8 support.
Looks to me like -e and -d are well documented in the help file under Using Password Safe/Command Line Arguments.
Perhaps a nice addition would be a Windows Explorer context menu item to execute those commands on selected files for those of us who like to stay out of the Command Line weeds. Of course, as you said, Rony, that digresses from the main purpose of Password Safe. Still, if the capability exists, then . . . ?
(There are many other alternatives to encrypting/decrypting files on the disk; for example, the free AxCrypt which uses AES-256 and the $29 WinRar which uses AES-128, both of which can create a self-extracting file.)
I think that maybe Bruce's objective or purpose of using PasswordSafe to encrypt files is to avoid using AES that the NSA "approves" of.
I have always tried to avoid AES whenever possible and always choose Twofish if it's available.
You're probably right, although even Securstar's Drivecrypt uses AES. But as the saying goes, "We don't know what we don't know."
What is the Password Safe encryption algorithm?
There was no "AES" at the time of Schneier's Password Safe.
Rijndael*, developed by Rijmen and Daemen - two EU cryptographers, was selected by NIST as the AES cipher at or about 2001.11. Six months later it was approved by US Gov/NSA.
PwSafe uses Twofish
*Rijndael 128-bit block
See below and attached file for example method
to create Right-Click Explorer context menu items
"Encrypt File with PasswordSafe",
"Decrypt File with PasswordSafe".
Adjust path to executable as necessary.
fernando: Cool -- Thanks!
I couldn't get it to work quite right the way you wrote it, but taking the "cmd" out and moving the quotation marks fixed it for me. This is how I changed registry entries 2 and 4 (as you said, the path needs to be adjusted to where Password Safe is installed):
For 32-bit Windows:
@="\"c:\program files\pwsafe\pwsafe.exe\" -e \"%1%\""
@="\"c:\program files\pwsafe\pwsafe.exe\" -d \"%1%\""
For 64-bit Windows:
@="\"c:\program files (x86)\pwsafe\pwsafe.exe\" -e \"%1%\""
@="\"c:\program files (x86)\pwsafe\pwsafe.exe\" -d \"%1%\""
(Not sure what the value added is for having to enter the key twice in the decryption stage, though)
Good you've got a working solution.
Better without superfluous command prompt.
If you are using Windows 7 you may have interest in mimicking a shell extention
with a cascading flyout menu:
How to Create Cascading Menus with the ExtendedSubCommandsKey Registry Entry
Rony indicates that he will alter the dialog so that the password need not to be entered twice for decryption.
I thought to chime in with some clarifications re prior posts in this thread:
1. B. Schneier did refer to the -e command, as he clarified in a subsequent blog entry.
2. AxCrypt uses AES-128 . WinRAR had used AES-128 up until the recent V.5, where this was changed to AES-256
3. The -e command, as opposed to AxCrypt, can not process large files. See
https://sourceforge.net/p/passwordsafe/feature-requests/702/
4. People who wish to use the -e/-d switch but do not want to deal with the registry can simplify the command prompt management by doing the following:
a. make sure the PWSafe is in the environment path
b. In Windows Explorer, where the file to be processed is listed, use SHIFT+RightClick (when nothing is selected) and in the pop-up menu you will have a new entry "open windows command here" (tested in WIN7). This will save you from dealing with folder navigation from the command prompt., letting you use the PWSafe in command mode where you are.
Last edit: Kob 2013-09-26
A bit more:
PWSafe up until V.3 (IIRC) used Blowfish, Since V.3 it has been using Twofish. I prefer either one over AES not because AES might have a backdoor(*), but because if somehow the NSA would put up the resources to crack a well-established encryption algorithm, AES would be the first choice due to its ubiquity. Regardless, in practical terms it is much more efficient to attack the implementation than the core algorithm, and open-source is not panacea - have any of you gone through every line of PWSafe to verify that there are no unexplained lines before personally compile it for his/her usage?
(*)the AES algorithm is well established, done by European researchers before the Patriot Act, easy to make sure that it has no "funny" constants like the recent EC RNG case, and one can compare the code and the encryption results to any published AES algorithm gathered from any of the many different sources for the last 12 years.
Last edit: Kob 2013-09-26
Rijmen and Daemen first published Rijndael 15 years ago.
@fernando thanks for the correction, I edited my post from "last 20 years" to "last 12 years".
I don't know if I failed to copy the registry information above correctly but I could not make those registry keys work. On Win 7 Pro 64 bit the values that ended up working for me are:
[HKEY_CLASSES_ROOT*\shell\PwSafe_1_Encrypt_File]
@="Encrypt File with PasswordSafe"
[HKEY_CLASSES_ROOT*\shell\PwSafe_1_Encrypt_File\command]
@="cmd /c \"C:\Program Files (x86)\Password Safe\pwsafe.exe\" -e %1"
[HKEY_CLASSES_ROOT*\shell\PwSafe_2_Decrypt_File]
@="Decrypt File with PasswordSafe"
[HKEY_CLASSES_ROOT*\shell\PwSafe_2_Decrypt_File\command]
@="cmd /c \"C:\Program Files (x86)\Password Safe\pwsafe.exe\" -d %1"
To use these, copy them to a text file, save it with a .reg extension and then import to the registry. All the usual scary warnings regarding the dangers of editing the registry still apply.
I just noted something odd with the registry information I pasted in above and I don't know if this is related to the problem I had using the original suggestions. Some of the strings do not appear as entered, and that makes me suspect that either Firefox or the forum software are treating some of the back slashes as special characters in the text box.
There SHOULD be a \ character before the * character in each of the registry keys above, and the paths to the Password Safe program entry SHOULD have double back slashes between folder names if this is to be used as a registry file import.
Thanks. Did you try what I posted earlier for 64-bit Windows (although it was just a piecemeal comment to Fernando's post)? "cmd /c" didn't seem to be necessary. Here's the reg file I exported which has been working fine in Windows 8 Pro. If it's not working properly after importing, check to make sure that the two command values are:
"C:\Program Files (x86)\Password Safe\pwsafe.exe" -e "%1%"
and
"C:\Program Files (x86)\Password Safe\pwsafe.exe" -d "%1%"
I'm not sure I tried yours correctly, I don't recall exactly how I edited in to the original .reg file suggestion, but I was not able to make it work. In fact, I was not able to make any of the versions that put the %1 into quotes work.
I guess since the registry keys as they appear in my post are not correct I should post the registry file I exported from regedit after I got everything set up correctly.
Last edit: Bill Osler 2014-04-13