L'implementazione del proprio SSL non è un piccolo sforzo. Ci vuole un certo sforzo per farlo funzionare a tutti; ci vuole un lotto di sforzi per farlo in modo sicuro. La crittografia in SSL è sottile e, in particolare, l'implementazione della crittografia simmetrica (con cifrari a blocchi) presenta alcune vulnerabilità se la decrittazione e la verifica MAC non vengono eseguite con la massima cura (funzioni di confronto a tempo determinato e così via).
Una volta ho scritto una libreria SSL in puro C, per un sistema embedded (ARM7TDMI). Ha supportato alcune suite di crittografia (con crittografia 3DES e AES). Comprendeva un primitivo sistema di convalida del percorso X.509 (un decodificatore ASN.1 streamable). L'ingombro del codice completo, una volta compilato, era di circa 20 kB; il supporto X.509 ha rappresentato 6 kB e 5 kB solo per l'AES (a causa delle sue tabelle interne precalcolate). Ancora più importante, la libreria non ha eseguito alcuna allocazione dinamica della memoria da sola; potrebbe funzionare con un singolo buffer da 18 kB fornito dal chiamante.
Se hai davvero bisogno di adattarsi alla più piccola dimensione del codice, devi implementare una suite di cifratura singola usando RC4. RC4 ha pregiudizi noti, quindi, crittograficamente parlando, fa schifo. Tuttavia, non richiede padding, il che evita molte delle vulnerabilità implicite nella gestione del padding al momento della decrittografia, quindi l'uso di RC4 in quel caso non è probabilmente una cattiva idea.
Non puoi evitare alcuna forma di scambio di chiavi. Altrimenti non avrebbe senso usare SSL. Esiste una "sessione HTTPS nullo": si chiama "semplice HTTP" senza alcun SSL. Lo scambio di chiavi basato su RSA è più semplice per il client, dal momento che comporta solo operazioni a chiave pubblica, vale a dire l'esponenziazione con un esponente molto piccolo. Sarà inoltre necessario per la convalida del certificato del server (verifica della firma RSA). Alcuni codici "grandi interi" fatti a mano con le poche operazioni necessarie possono essere creati con poche righe di codice, ma ovviamente devi capire cosa stai facendo.
Leggi questa risposta per una descrizione del protocollo SSL / TLS. Ottieni anche il Manuale di crittografia applicata (download gratuito!), In particolare il capitolo 14, che tratta (in particolare) di numeri interi aritmetica.
E ottieni la revisione del tuo codice. Non immaginare di poter scrivere codice senza vulnerabilità; essere pronti a fare di nuovo il lavoro. Un progetto software dovrebbe essere scritto tre volte: una volta per capire il problema, una volta per capire la soluzione e una volta per farlo correttamente. Dal momento che le vulnerabilità non vengono visualizzate durante i test funzionali, l'unico modo per rilevarle è inviare il tuo codice a diverse (molte) altre persone e fargli trovare problemi.