OK, primo commento assolutamente obbligatorio: NON ROTOLARE IL PROPRIO PROTOCOLLO DI ENCRYPTION O SCRIVERE LA PROPRIA ATTIVAZIONE DELLA CRITTOGRAFIA. Non farlo. Mai. Non importa quanto sia grande un programmatore; se non hai molta conoscenza e pratica con crypto e un gruppo di revisori peer con esperienza simile e competente, rovinerai qualcosa. Crypto è estremamente difficile da ottenere correttamente, pieno di casi limite, esigenze contro-intuitive e canali secondari inattesi ... e se non riesci a tenerne conto anche solo uno, indebolirai il tuo schema, molto probabilmente il livello di compromesso completo.
Modifica
OK, non ho familiarità con lo schema descritto in quel documento. Detto questo, la roba di seguito - per l'uso con normale scambio di DH, non questa curiosa novità - potrebbe non essere appropriata. Tuttavia, la domanda che hai chiesto, "Come eseguire la crittografia dopo Diffie Hellman Key Exchange", viene data risposta di seguito ... eccetto, ovviamente, che la vera risposta è "non lo fai, usi una libreria che la gestisce per te ".
Ok, con quello fuori mano ... una volta che hai estratto la chiave simmetrica dallo scambio DH, usala in un cifrario crittografico simmetrico! Ci sono molte tra cui scegliere, ma il più comune è probabilmente AES , usando una chiave a 128-bit o 256-bit , in modalità CBC , con Padding PKCS7 , utilizzando un strong generato a caso IV e con un HMAC del testo cifrato per l'integrità. Se la chiave condivisa è la lunghezza sbagliata per il codice, puoi eseguirlo tramite una funzione come SHA-256 per produrre una chiave adatta per AES a 256 bit.
Puoi inviare la IV e l'HMAC in chiaro; sono inutili per un utente malintenzionato senza la chiave e il destinatario previsto deve conoscerli. Il destinatario prende il testo cifrato, ricalcola l'HMAC e verifica che corrisponda, quindi utilizza l'IV fornito e la chiave simmetrica condivisa per decodificare il messaggio utilizzando lo stesso codice AES in modalità CBC.
Non posso sottolineare abbastanza strong quanto sia essenziale che tu faccia NON per farlo come se non fosse una curiosità. Non pubblicare questo codice. Non incorporarlo in qualcosa che potresti mai pubblicare. Non costruire niente altro su di esso. Non fidarti di nulla inviato tramite questo sistema. Non dare per scontato che abbia caratteristiche di sicurezza significative. Idealmente, non attaccarlo nemmeno nel tuo GitHub o altro ... ma se devi, includi un commento in alto molto chiaramente che esclude l'idoneità del codice da utilizzare per qualsiasi cosa qualunque .
Ci sono passaggi che ho eluso o lasciato troppo vago. Ci sono almeno una dozzina di modi in cui potresti rovinare anche solo le parti di cui ti ho parlato, non preoccuparti di tutte le altre cose che devi fare. C'è un sacco di cose che sospetto tu abbia già fatto di sbagliato nel tuo scambio di chiavi. Ci sono un sacco di cose che sono sicuro di non sapere nemmeno che sono sbagliate, ma che stai sbagliando.
Sono stato in InfoSec professionalmente per otto anni, con un interesse per la crittografia che risale a quattro anni prima di quello, ea questo punto quando rivedo il codice crittografico nostrano posso dare due risposte significative: "È rotto" e "Probabilmente è rotto". Non ne so abbastanza per affermare anche provvisoriamente che qualcosa di cresciuto in casa è non rotto, e che probabilmente sarà vero per il resto della mia carriera a meno che non decida di dedicare un decennio della mia vita a questo area specifica di sicurezza. Crypto è difficile!
Esistono librerie, scritte da persone che conoscono meglio la cripto di praticamente chiunque altro vivo oggi, che svolgeranno praticamente qualsiasi compito crittografico che tu chiedi a loro. Esistono protocolli, progettati da persone con esperienza simile e implementati con grande esperienza in quelle librerie, che trasformano primitive crittografiche (come lo scambio di chiavi DH) in un criptosistema utile. Anche così , bug e debolezze in queste librerie si trovano sempre ... ma almeno sono risolti rapidamente. NON farai di meglio da solo.