Why is recipient hashed in this Sign/Encrypt/Sign proposal?

By | June 13, 2018

Own research

In my journey into trying to understand PGP, and public key singing and encryption as a whole, I came across this answer on CE. It is an answer to a question with the title: Should we sign-then-encrypt, or encrypt-then-sign? Although this satisfies my original quest, it has an interesting link to an article called: Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.. The article as a whole explains why "naive sign & encrypt" systems are not as secure as most people think. Also it proposes some solutions to the issue.

Question

A proposal which caught my attention from section 5.2 Sign/Encrypt/Sign of the article.

Surprisingly, we can get an effective repair for S&E, if Alice signs and encrypts the plaintext, and then she signs the ciphertext, too:

A ---> B   :   {{{msg}a}B , #B}a

(Here, #B means Alice hashes Bob's key, not his name.)

This message means:

  • Inner Signature: "Alice wrote the plaintext;"
  • Encryption: "Only Bob can see the plaintext;"
  • Outer Signature: "Alice used key B to encrypt."

[...]

Is there any cryptographic / security reason why the Alice would Hash Bob's public key? If I would implement something like:

A ---> B     :   {{{msg}a}B , B}a

(B is Bob's public key, not hashed)

Would I still benefit from the security offered by this fix?

Background

I'm in the research phase of developing a messaging platform based on public key encryption. My first intend was to use the openPGP standard. However, this standard alone would make it impossible to identify the sender until the message is decrypted. I want to offer end-to-end encryption, but in the same time, offering my servers to verify the sender is a registered user.

Off course, this could (and will) be done by client - server authentication. But even in such a case, using openPGP and authentication alone, a client can still misbehave:

PGP's strongest security option is naïve Sign & Encrypt, so PGP is vulnerable to surreptitious forwarding:

A ---> B   :   {{ "The deal is off." } a}B
B ---> C   :   {{ "The deal is off." } a}C

The server wouldn't know that Bob is illegally forwarding Alice's massage and gladly forward the message to Charlie on Alice's behalf.

I know that most of this can be prevented on application level. Like e-mail is doing with authenticated SMTP and fields like From: and To. But as an experiment, why not fix this issues directly in the cryptography protocol? I think, the server reading the intended receiver's public key would be a nice solution.