I need securely asymmetrically encrypt the up to 16 bytes plaintext and receive up to 32 bytes ciphertext. I found that ElGamal produces ciphertext that is 2 times keysize. So I would need to use 128bits keysize, which are not secure enough. I can use any keysize, but the ciphertext must not exceed 32bytes. Is it possible with other schemes?
$\begingroup$
$\endgroup$
5
-
$\begingroup$ Public key cryptography are never bandwidth-efficient. There's no solution whatsoever that meets your requirement. Your system/software/protocol/design must adapt. $\endgroup$– DannyNiuCommented May 11, 2020 at 9:31
-
$\begingroup$ For proper pk-crypto, the smallest (somewhat secure) overhead I'm aware of is around 40-48 bytes. $\endgroup$– SEJPMCommented May 11, 2020 at 9:39
-
$\begingroup$ @SEJPM ECIES would get to 32 + 16 = 48 bytes using a compressed public point as key, but that would still be without message integrity / authentication of course. $\endgroup$– Maarten Bodewes ♦Commented May 11, 2020 at 11:03
-
$\begingroup$ @MaartenBodewes yeah, 32 bytes should buy you a DH public key, e.g. with curve25519 and the 16 bytes buy you the CPA -> CCA2 upgrade. Sender authentication and replay protection is indeed a different beast. $\endgroup$– SEJPMCommented May 11, 2020 at 11:08
-
$\begingroup$ I'm wondering a bit if you can use the static key pair to derive a public key for a ephemeral key pair giving a value of only 16 bytes. But at the moment it's just that: a thought experiment. $\endgroup$– Maarten Bodewes ♦Commented May 11, 2020 at 12:16
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
The solution that worked for me was to derive a shared key via DHKE. And then, encrypt the message with AES. Since the message is authenticated and I know its public key, I can use it to derive a shared key with DHKE, during decryption as well.