Own research
In my journey into trying to understand PGP, and public key signing 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 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 intention 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 at 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 the application level. Like e-mail is doing with authenticated SMTP and fields like From: and To. But as an experiment, why not fix these issues directly in the cryptography protocol? I think, the server reading the intended receiver's public key would be a nice solution.
