Some systems, that operate over flaky bearers, need to send signed, encrypted messages that are entirely self contained - i.e. send a single 300 byte UDP rather than have a 10Kb, two-way, certificate conversation over TCP.

Assume the destination has a private key and already knows the source's public key, and the source has a private key and already knows the destination's public key.

Given this assumption, is there a standard for encrypting/signing a small, but arbitrary length, message?

(I'm well aware of the dangers of rolling my own encryption scheme.)

Would there be a minimum ciphertext size that is related to the public key size?

(I'm thinking plain PKI encryption for plaintexts shorter than the key, and a PKI encrypted AES key for longer plaintexts.)

  • $\begingroup$ PGP, S/MIME perhaps? $\endgroup$ – SEJPM Aug 21 '15 at 16:11

Would there be a minimum ciphertext size that is related to the public key size?

It depends on the algorithms used. An RSA signature, without any bells and whistles, is equal to the key length in size (i.e. 2048 bits for 2048-bit RSA). Likewise raw RSA encryption adds the same. So if you just use both, you add twice the key length, or 512 bytes for a 2048-bit key size.

Elliptic curves allow much more compact signatures and encryption. An 256-bit ECDSA signature is usually 512 bits. With NaCL, using Curve25519 and hybrid encryption, you can get authenticated encryption using only 40 bytes of extra space. That's what I would likely use with small messages.

If even elliptic curve algorithms add too much, you could use symmetric algorithms, with an occasional session key exchanged using the public key system. If many messages are exchanged using, say, AES GCM your per message overhead is about nonce size + authentication tag size (e.g. 192 bits total). Even less if you can use some existing counter as the nonce.

| improve this answer | |
  • $\begingroup$ flexiprovider.de/examples/ExampleECIES.html might be useful, I will test it soon. $\endgroup$ – fadedbee Aug 23 '15 at 4:51
  • $\begingroup$ ECIES is exactly what I was looking for. There is a Bouncy Castle implementation for Java. It adds about 100bytes to each message when using a 256k1 key (like bitcoin uses). $\endgroup$ – fadedbee Aug 30 '15 at 11:42

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.