6
$\begingroup$

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 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 (too little time to look into this further, need to kayak now). $\endgroup$ – Maarten Bodewes Jun 13 '18 at 16:35

Your Answer

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

Browse other questions tagged or ask your own question.