libhydrogen icon indicating copy to clipboard operation
libhydrogen copied to clipboard

Is there a way to do signcryption with this library?

Open creationix opened this issue 1 year ago • 7 comments

I really like the minimalism of this library for embedded use cases.

I'm designing a protocol where I want authenticated messages stored in relays to be encrypted at rest and only readable if you know the public key.

The relay will index the messages by a hash of the public key (similar to how dat works) so that the relay never even knows the public keys and can never decrypt the messages. But any client that knows the public key can ask for the messages from the relay and decrypt and authenticate them.

Is encryption alone enough to authenticate or is something else needed?

creationix avatar Mar 14 '23 17:03 creationix

If the public key of the recipient is not known, the shared secret cannot be recovered.

Signcryption doesn't seem necessary here, unless the relay needs to verify the sender's identity without being able to decrypt the content.

jedisct1 avatar Mar 14 '23 21:03 jedisct1

The relay doesn't need to verify anything. Maybe I misunderstood what signcryption does.

What I want is a system where:

  • A message is encrypted end-to-end (relays can't read it)
  • The sender doesn't know any keys of the receiver.
  • The receiver only knows the sender's public key and wants to verify the message comes from sender via that public key.
  • The relay doesn't know the sender's public key, only a hash of it (it's semi public)

My construction idea is:

  • Sender encrypts a message using their private key (similar to signing, but the whole message is encrypted not just the content digest)
  • how do I encrypt the bulk message using a private key? I assume I want to embed some kind of symmetric key that is encrypted right?

creationix avatar May 16 '23 16:05 creationix

The sender doesn't know any keys of the receiver. Sender encrypts a message using their private key

In that case only the sender can decrypt their own message. The recipient cannot do anything with it. Is it what you want?

jedisct1 avatar May 16 '23 16:05 jedisct1

The receiver knows the sender's public key. Isn't that enough to decrypt the message?

My understanding is this is similar to a normal digital signature.

In signature:

  • message is hashed and that hash is encrypted using the sender's private key
  • receiver decrypts the hash using the sender's public key and verifies the hash matches the message.

What I want:

  • sender encrypts the message with a random symmetric key
  • sender encrypts the key using their private key
  • receiver decrypts the shared key using sender's public key
  • receiver decrypts message using symmetric key

Am I misunderstanding something fundamental about these primitives?

creationix avatar May 16 '23 20:05 creationix

I think I'm misunderstanding the primitives. This clears it up for me a bit

creationix avatar May 16 '23 20:05 creationix

I think ECIES might be what I'm looking for. But I also saw that maybe I shouldn't use the same keypair for that as used for signatures.

creationix avatar May 16 '23 20:05 creationix

Or what I want without specifying implementation details:

  • sender encrypts a message and publishes it publicly without disclosing the corresponding public key, only a hash of the public key
  • authorized readers know from a side-channel how to resolve the hash back to the original public key and only they can decrypt and authenticate it.

Is ECIES the correct construction for this using ECC? If so, is this possible with this library?

creationix avatar May 17 '23 17:05 creationix