0

As said in the title, I've to encrypt a message with RSA, generate a signature, and transmit everything over CAN-FD (suppose keys are already been exchanged). The problem is that a CAN-FD frame supports a total of 64 bytes of payload, but how many bytes will I have after encryption (using a 2048 bit key) and signing? Does it depends on the want-to-transmit message length?

0

Encrypting the message itself using RSA is bad practice. You should use hybrid encryption.

Encrypting using the long term RSA key of the recipient is bad practice because it does not provide forward secrecy. Leaking the long term key allows retroactive decryption of all past messages. This was considered ok in the 1990s but is not allowed today. In new protocols, you must use Diffie Hellman (usually, ECDH, these days X25519) to establish random per-session or per-message key that itself is not encrypted using your long term key. The long term identity key should only be used for authentication.

First choose the AEAD mode that you want to use for the symmetric part.

AES-GCM is popular. AES-EAX is preferred by Google on hardware that has AES circuits.

ChaCha20-Poly1305 is recommended if your hardware doesn't have a hardware circuit for AES. I would use XChacha20-Poly1305 (extended nonce version) because then I don't need to worry about nonce reuse and about insecure software AES.

If you can't use those, you can use AES-CTR with HMAC-SHA2, with the MAC covering the nonce (if you use CTR with nonce and counter and not only counter), in encrypt-then-MAC, MAC-then-decrypt mode. This is also secure.

AES-CBC with random IV and HMAC-SHA2 is also secure, with the MAC covering the IV and again in encrypt-then-MAC, MAC-then-decrypt mode. This is slower to encrypt, but you probably don't care.

After you have your AEAD mode, you look how many random bytes you need to encrypt a message. You generate that many random bytes and use them to encrypt the cleartext. You need to send the ciphertext, the nonce and the MAC to the other side. You encrypt the random bytes you used using RSA-OAEP (RSA PKCS#1 v1.5 is bad). You sign the whole thing using RSA-PSS (RSA PKCS#1 v1.5 is bad).

You send the ciphertext of the message itself. If you chose CBC, your message gets padded up to 16 bytes. Otherwise, no padding.

You need to send the nonce or IV, so add that. Size depends on AEAD mode.

You need to send the MAC, so add that. Size depends on AEAD mode.

The RSA-2048 encryption of the random bytes is 256 bytes, regardless of message size.

The RSA-2048 signature over the whole thing is 256 bytes, regardless of message size.

Using X25519 and Ed25519 signatures would produce shorter messages than RSA-2048.

If you use Noise Framework, you don't need Ed25519 code, it uses long term X25519 keys and HMAC for authentication.

Combining all those primitives into a protocol yourself is likely to be insecure, you are much better off using Google Tink or libsodium or some other high level misuse resistant API.

0

Finally found it, don't why it took so long: 2048 bit after encryption, because doesn't depend on the length of the message to encrypt, and 256 bytes of signature. So 512 total bytes to transmit in 8 different 64-bytes CAN-FD frames.

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.