News Feed
- DrugHub has agreed to fully refund all users who lost money in the SuperMarket exit scam.
- Retro Market has gone offline. Circumstances of the closure unknown.
- SuperMarket has closed following an exit scam by one of the admins.
- The admin of Incognito Market, Pharoah, has been arrested by the FBI several months after exit scamming.
- Silk Road
- darknet markets list
- Popular P2P exchange LocalMonero has announced it is closing.
Kleopatra will often crash for me attempting to decrypt a message that has unknown keys (More than two, the person you are talking to and yours). USUALLY closing and re-opening the software alleviates this. If not, I use gpg from the command line or gpa (GNU privacy assistant) to decrypt the message. I also don't write a message in Kleopatra notepad when this happens, too often Kleopatra will crash and I have to start over. I've learned my lesson there.
gpg4usb is outdated and should not be used.
If I missed your point, let me know what you meant with more clarity.
User A necrypts message with Kleopatra
User B cannot decrypt for some reason
User A encrypts same message using same public key, but this time uses gpg4usb (just to test)
User B successfully decrypts the new message
-----
I have heard twice now that this problem experienced by user B only happens when the sender uses Kleopatra to encrypt the message
If user A owns one of those, he's likely to have trouble exchanging with legacy software like Gpg4Usb (last updated 9 years ago). The PGP message payload will obviously match the recipient RSA public key; however, additional information, such as metadata (
timestamp, recipients), signature, or co-recipients payloads could be build on top of ECC encryption. This is likely to create a conflict when processing the full message for decryption.When user A tries again using Gpg4Usb, he has to generate a new, RSA compliant key. Messages extended with this new key are 100% RSA and can, therefore, be decrypted by user B.
I would think it's a bit of both. When there are both RSA and ECC recipients, I'd assume the message payload will contain parts encoded with one, then the other algorithm. Signature are clearly shorter when generated with an ECC key, which suggests the encryption algorithm also matters here. I'm less sure about metadata (my bad) as the specification seems to indicate it's algorithm independent (also it's only fingerprints, date only matter for signing).
Any case I can imagine the PGP version to matter for parsing. Interestingly enough, it is included in the messages for compatibility reasons. One can remove it using the following parameter:
Also sorry for the double post :) Had a connection issue earlier.
worth notting the message succesfully encrypted has a version ""header"" specifying GnuPG v1 - almost definintely a breaking change from v1->v2.xyz