6
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ In general the signature calculation will already perform some kind of hashing. I don't see how leaving out the hashing step can somehow break security for that reason alone. Using the additional hashing will reduce the resulting message - otherwise I don't see the benefit of it. $\endgroup$ – Maarten Bodewes Jun 13 '18 at 16:35
0
$\begingroup$

I don't fully understand the notation in that link you posted, but as far as hashing the public key instead of signing it directly, some public keys are pretty long, making signing expensive. Public keys for RSA can be 4096 bits, which is too long for most signing schemes. Hashing the public key allows it to be signed more efficiently without losing security.

| improve this answer | |
$\endgroup$
  • $\begingroup$ In the comment I made below the post I wrote "In general the signature calculation will already perform some kind of hashing.". Can you explain your answer more with this remark in mind? $\endgroup$ – Maarten Bodewes Jun 12 at 7:52
  • $\begingroup$ Ah, I didn't see that comment. They could be trying to write their protocol without the assumption that the signing scheme would hash the message. But usually authors make this assumption to err on better security, not performance, so I'm not sure. $\endgroup$ – HappyPandaFace Jun 12 at 17:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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