Join Log in
Score:0
avatar Crypto

Generating private keys based on the list of ciphersuites available

my flag
user1398593

I am building my own MQTT based network for which I would generate my own ca/server/client certificates for authentication.

The goal here is to keep the message sizes as small as possible so as to reduce the bandwidth traffic, but I already know that the TLS layer adds quite an overhead to the traffic it sends. Namely, with the client certificates, I would actually have to send the client certificate to the server and vice versa on each TCP connection attempt which can add up to 8kb without even sending one byte of real data. (I hope I got that part right so far)

Also, since a lot of my clients are small embedded devices which only have a limited number of ciphersuites they can use the matter is complicated even more.

For example this is the allowed list of ciphersuites a client can use:

CIPHERSUITE CODE
TLS-PSK-WITH-AES-128-CBC-SHA256 00ae
TLS-PSK-WITH-AES-256-CBC-SHA384 00af
TLS-PSK-WITH-AES-128-CBC-SHA 008c
TLS-PSK-WITH-AES-256-CBC-SHA 008d
TLS-PSK-WITH-3DES-EDE-CBC-SHA 008b
TLS-RSA-WITH-AES-128-CBC-SHA256 003c
TLS-RSA-WITH-AES-256-CBC-SHA256 003d
TLS-RSA-WITH-AES-128-CBC-SHA 002f
TLS-RSA-WITH-AES-256-CBC-SHA 0035
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA c013
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA c014
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 c027
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 c028

Now in this example the only ciphersuites available are PSK and RSA based ones. Of course I would love to use the EC ciphersuites but I don't think this is an option for me given the list.

Now a couple of questions I have are:

  • Given the ciphersuite list can any of the private keys (CA, Server or Client) be EC based or do they all have to be RSA?

  • Should I also keep individual MQTT packages that are wrapped with TLS as small as possible or is this something which will be padded with additional bytes? (e.g. will it make a difference if my package is as small as 5 bytes or can I freely write a package that is 25 bytes long)

  • What are some other things I should keep in mind if I want to reduce the traffic bandwidth?

  • ECDHE-RSA ciphersuites are giving me a headache. They are using EC for key exchange but RSA for PKI ? Does this mean that a server can have EC private key.

43
0 + 0
dave_thompson_085 avatar
cn flag
dave_thompson_085
To be clear for any non-PSK suite you must send the server cert to the client, and for ECDHE-RSA also a signature; client-auth is optional but if used you must also send the client cert _and_ signature to the server. Generating your own certs with minimal content, for 2048-bit RSA you can get each to about 700-800 bytes. Except for 1.3 which your suites aren't, the rest of a standard handshake including client-auth signature can be about 700-1000 bytes more. You can do lots of data (as much as devices llike yours can do) with one handshake.
0
Reply
Score:1
Maarten Bodewes avatar Crypto
in flag
Maarten Bodewes

Given the ciphersuite list can any of the private keys (CA, Server or Client) be EC based or do they all have to be RSA?

No only RSA, or a pre-shared symmetric secret for TLS-PSK of course.

Note that for the TLS-RSA ciphersuites the key will be used for key encapsulation, i.e. the encryption key usage and the TLS-ECDHE-RSA ciphersuites you need a certificate that can be used for entity authentication with the key usage for signing. Often both bits are set for TLS specific certificates.

Should I also keep individual MQTT packages that are wrapped with TLS as small as possible or is this something which will be padded with additional bytes? (e.g. will it make a difference if my package is as small as 5 bytes or can I freely write a package that is 25 bytes long)

AES will encrypt to a multiple of 16 bytes, 3DES to a multiple of 8. 3DES is still reasonably secure, but it should not really be used anymore. Fortunately TLS uses 3 key 3DES, so there's that.

ECDHE-RSA ciphersuites are giving me a headache. They are using EC for key exchange but RSA for PKI ? Does this mean that a server can have EC private key.

Correct, but the E in ECDHE means ephemeral-ephemeral Diffie-Hellman. Both the client and server will (likely/hopefully) generate a new key pair for each connection. Key pair generation for EC is about as fast as performing the DH key agreement itself though, it is much faster than RSA key pair generation.

This key pair is session specific and doesn't need to be stored, so you don't have to perform any key management around it. Only the RSA key is used for entity authentication so the private key and certificate does need to be managed.

0 + 0
dave_thompson_085 avatar
cn flag
dave_thompson_085
In addition to padding to block boundary for encryption, the listed suites add at least 20 bytes (some 24 or 32) for HMAC, and all add a header of 5 bytes (or 13 for DTLS but that _removes_ TCP which more than compensates).
2
Reply
my flag
user1398593
However MQTT does not use DTLS? Only TLS over TCP, right?
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.