L'implementazione della tua crittografia potrebbe essere soggetta a errori, quindi ti preghiamo di non farlo.
Se si sta tentando di crittografare i dati in transito tra l'app e il back-end (ovvero fornire riservatezza per quella trasmissione), è probabile che l'utilizzo di una connessione HTTPS sia interamente sufficiente. Sia l'app che il server vedranno il messaggio non crittografato.
Si noti che tutte le autorità di certificazione accreditate dal dispositivo che esegue l'app possono emettere certificati per il proprio sito. Viene spesso utilizzato nelle reti aziendali per intercettare qualsiasi traffico crittografato, ma generalmente viene fatto con la conoscenza dell'utente finale. È possibile impedirlo se l'app inserisce il certificato corretto, ma ciò potrebbe interrompere l'app se è necessario modificare il certificato sul server. Questo non è qualcosa che dovresti fare generalmente, ma è importante conoscere i limiti di HTTPS nel caso in cui si tratti di dati altamente sensibili: HTTPS fornisce riservatezza ma non necessariamente autenticazione.
HTTPS funziona all'incirca come il tuo secondo esempio. Il server fornisce una chiave pubblica. Questa chiave è firmata da un'autorità di certificazione (CA). La CA deve verificare che questa chiave pubblica appartenga al dominio a cui ti stai connettendo. La chiave è accettata quando il dispositivo dell'utente finale si affida alla CA di firma. Ora il client può inviare messaggi al server utilizzando la chiave pubblica del server e solo il server è in grado di decodificare questo messaggio. Viene utilizzato per negoziare una chiave di sessione simmetrica di breve durata che consente una comunicazione più efficiente. Ora che la chiave della sessione segreta è stata scambiata, il server e il client possono parlare tra loro su un canale crittografato.
Una chiave privata non dovrebbe mai essere trasmessa. L'intero punto della crittografia pubblica / privata è che non è necessario condividere una chiave segreta per decodificare i messaggi.