Suggestion: (1) decrease metadata leakage & (2) added security.

[DiagonalArg]

Thanks again for your work! ... Two suggestions:

(1) You might add a checkbox next to "Recipients" that would allow us to use the "--hidden-recipient" option in gpg. That way out messages leak less metadata.

(2) I am just reading this: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

Some of the work-arounds to the security problems described there involve the computation of a hash of the message or the message combined with a name. I'm wondering if this could be done within pyrite. For example: select area, right click >> compute SHA256, and the result is put on the clipboard. Then we can paste to the appropriate place and start signing/encrypting.

Thanks!
/DA

[ryran]

You might add a checkbox next to "Recipients" that would allow us to use the "--hidden-recipient" option in gpg. That way out messages leak less metadata.

Indeed. I could add that. I don't have time for this right now (as you probably suspected what with the lack of response for so long), but I'm hopeful that I can spend some time on it in the next month.

I am just reading this: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html ...

I don't have time to read that right now, but color me skeptical if it's trying to say that modern GnuPG is susceptible to some sort of attack that can be easily checked by simply having an independent hash of the original input text (or cipher text -- I can't tell which you're saying from your suggestion).

I highly recommend posting a request for comment to the gnupg-users mailing list (http://lists.gnupg.org/pipermail/gnupg-users/) before trusting the conclusions of a paper from at least 15 years ago.

[ryran]

PS: I just noticed that I created an issue for hidden recipients a while ago... #11
sigh

[DiagonalArg]

You'll get around to it, Ryan. It's a valuable tool, so you won't let it die. ;)

Edited

... color me skeptical if it's trying to say that modern GnuPG is susceptible to some sort of attack that can be easily checked by simply having an independent hash of the original input text (or cipher text -- I can't tell which you're saying from your suggestion).

No, this is about the sign-then-encrypt vs the encrypt-then-sign question:

• encrypt-then-sign is problematic. It leaks metadata since the signature is outside; and, someone could replace the signature with their own. (Signing the ciphertext rather than the plaintext is particularly dangerous as, in the case of El Gamal, there is an ("Anderson") plain-text replacement attack.) (See section 1.2 at that link.)
• sign-then-encrypt. Better, but susceptible to a replay attack. The message could be decrypted by John and re-encrypted to Mark. You can repair this by putting in the outgoing message, "This message is meant for John," or somesuch. There are other approaches (see section 5.)

The various repairs all have a common feature: when signing and encryption are combined, the inner crypto layer must somehow depend on the outer layer, so as to reveal any tampering with the outer layer.

Some of those repairs depend on being able to hash the message or the recipient key. This is why I'm suggesting you offer a convenient way to compute a hash.

Update

On second reading, we don't need a function to compute a hash of the message as I was suggesting. Your signature tool is already sufficient and provides for three approaches that work:

• sign-&-encrypt while remembering to introduce the recipient name in the plain text (5.1.1)
• encrypt-&-sign while remembering to introduce the sender name in the plain text (5.1.2)
• encrypt-&-sign-&-encrypt (5.3)

There are three other repairs that necessitate a hash of the recipient key:

• encrypt-&-sign (a variant of 5.1.2, described in 1.2, equation 13)
• sign-&-encrypt-&-sign (5.2)
• encrypt-&-sign-&-encrypt (a variant of 5.3, described in 1.2, equation 13)

Those that end in a signature leak metadata. I just thought I'd put that all there for anyone else who comes this way.

[DiagonalArg]

(Edited prior comment.)