Având în vedere lista ciphersuite, oricare dintre cheile private (CA, Server sau Client) poate fi bazată pe EC sau trebuie să fie toate RSA?
Nu numai RSA, sau un secret simetric pre-partajat pentru TLS-PSK, desigur.
Rețineți că pentru suitele de criptare TLS-RSA, cheia va fi folosită pentru încapsularea cheii, adică pentru utilizarea cheii de criptare și pentru suitele de criptare TLS-ECDHE-RSA aveți nevoie de un certificat care poate fi utilizat pentru autentificarea entității cu utilizarea cheii pentru semnare. Adesea, ambii biți sunt setați pentru certificate specifice TLS.
Ar trebui să păstrez, de asemenea, pachetele MQTT individuale care sunt împachetate cu TLS cât mai mici posibil sau este ceva care va fi umplut cu octeți suplimentari? (de exemplu.va face o diferență dacă pachetul meu este de 5 octeți sau pot scrie liber un pachet care are 25 de octeți)
AES va cripta la un multiplu de 16 octeți, 3DES la un multiplu de 8. 3DES este încă relativ sigur, dar nu ar trebui să mai fie folosit cu adevărat. Din fericire, TLS folosește 3DES cheie, așa că există asta.
Suitele de cifrare ECDHE-RSA îmi dau bătăi de cap. Ei folosesc EC pentru schimbul de chei, dar RSA pentru PKI? Înseamnă asta că un server poate avea cheie privată EC.
Corect, dar E în ECDHE înseamnă efemer-efemer Diffie-Hellman. Atât clientul, cât și serverul vor genera (probabil/sperăm) o nouă pereche de chei pentru fiecare conexiune. Generarea perechii de chei pentru EC este la fel de rapidă ca și realizarea acordului de chei DH în sine, totuși, este mult mai rapidă decât generarea perechii de chei RSA.
Această pereche de chei este specifică sesiunii și nu trebuie să fie stocată, așa că nu trebuie să efectuați nicio gestionare a cheilor în jurul ei. Numai cheia RSA este folosită pentru autentificarea entității, deci cheia privată și certificatul face trebuie gestionate.