Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote -1 down vote favorite

Let's say I made my private key using Enigmail. Then I imported it into a Windows program called GPG4USB. When I want to decrypt a message it asks for my encryption password but it doesn't accept the password I provided with Enigmail originally. Both software are derivatives of GnuPG. Am I understanding it correctly that different implementations are not compatible with each other or am I doing something wrong?

share|improve this question
1  
Your question is off-topic here, since it isn't about security, it's about using Gpg4usb and Enigmail. You could ask this question on Super User, but be sure to give more information, because as asked here the question is not answerable. For a start, you talk about making a private key, but then decrypting with a password: which one is it? Explain exactly how you configured the programs and exactly what you did to create and attempt to decrypt the message. – Gilles Jan 20 at 14:24

closed as off topic by Gilles, AJ Henderson, Iszi, Scott Pack, this.josh Jan 22 at 18:10

Questions on IT Security Stack Exchange are expected to relate to IT security within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.

1 Answer

up vote 1 down vote

Someone is doing something wrong, but not necessarily you. GnuPG follows the OpenPGP format, which is a standard.

The format includes provisions for using several cryptographic algorithms; not all implementations support all of them. However, GnuPG tends to implement the same algorithms as... itself.

The usual suspect for password interoperability issues is encoding: passwords are characters but must be converted to bytes in order to do cryptography with them. If you have a non-ASCII character in your password, it is possible that one front-end used latin-1 (or a superset such as Windows-1252) while the other preferred UTF-8, resulting in a distinct sequence of bytes for the same password. Even with ASCII, you can get issues with UTF-16, which is not ASCII-compatible.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.