Il tuo problema è la trasmissione di un dato segreto; che il pezzo di dati è una chiave crittografica è per lo più irrilevante (significa solo che è veramente segreto). Quindi, quello che vuoi si riduce a essere sicuro di chi ottiene.
Dato che parli di processi, presumo tu stia parlando di un trasferimento all'interno di una singola macchina . "Chi" dipende quindi dal modello di sicurezza del proprio sistema operativo. Il sistema operativo comune utilizza un modello con "account", ciascun processo essendo collegato a uno di tali account e con i privilegi associati a tale account. C'è un "account principale" (root su Unix, Amministratore su Windows) che ha tutti i diritti e non puoi difenderci da questo.
Detto questo, vediamo le tue proposte:
- " Come valore di ritorno ": questo non può essere applicato. Un "valore di ritorno" è ciò che viene inviato da una funzione al relativo chiamante all'interno di un singolo processo. Nel tuo caso, ci sono due processi.
- " Scritto su un file ": vorrei sconsigliarlo. Un file lascia tracce. Una volta che i dati sono passati a un supporto fisico, devi mantenere i controlli di accesso su questo mezzo per sempre . Sembra meglio mantenere il tutto nella RAM il più possibile.
- " Crittografia e socket ": la crittografia va bene finché hai già distribuito le chiavi, quindi stai risolvendo il problema dell'uovo e della gallina affermando che hai già un altro uovo / pollo , che non risolve le cose. D'altra parte, per un socket che è local su una macchina, potresti avere il modo di assicurarti che il processo all'altra estremità del socket sia di proprietà dell'account previsto; si chiama
getpeereid() su sistemi di tipo Unix.
- " Comunicazioni tra processi ": questo è un nome generico per i modi in cui due processi possono comunicare tra loro e include socket locali. La scelta è ampia (e molto dipendente dal sistema operativo); il punto importante è che puoi ottenere l'ID utente effettivo dell'altro processo, come
getpeereid() .
Su un sistema simile a Unix, puoi usare un socket locale, anonimo (creato con socketpair() ) o named (un "dominio dominio Unix", così com'è); una coppia di socket anonimi è possibile se i due processi hanno una relazione padre-figlio che consente loro di scambiare i descrittori di file. Puoi anche usare pipe, di nuovo anonimo, o attraverso un punto di rendez-vous basato su file (una "named pipe"), in cui il filesystem contiene l'area della riunione, ma i dati rimangono puramente nella RAM. Memoria condivisa SysV, mmap() con MAP_SHARED su /dev/zero , ... ci sono molte possibilità, ciascuna con i propri metodi per i controlli di accesso.
Su un sistema Windows, le possibilità sono ancora più varie, a causa della lunga storia dei successivi livelli di inventiva in questo sistema operativo (non lasciano mai nulla - sono compatibili con la retrocompatibilità - ma riprogettano anche interi sottosistemi ogni due anni, quindi i metodi IPC tendono ad accumularsi: nel 2003, ho contato non meno di 9 metodi per questo, e sono sicuro che ora ce ne sono altri).