Su problema es la transmisión de un dato secreto; que la pieza de datos sea una clave criptográfica es en su mayoría irrelevante (solo significa que es realmente secreto). Por lo tanto, lo que desea se reduce a asegurarse de quién lo obtiene.
Dado que habla de procesos, asumo que está hablando de una transferencia dentro de una sola máquina . "Quién" depende del modelo de seguridad de su sistema operativo. El SO común utiliza un modelo con "cuentas", cada proceso está vinculado a una de esas cuentas y tiene los privilegios asociados con esa cuenta. Hay una "cuenta maestra" (root en Unix, Administrator en Windows) que tiene todos los derechos, y no puede defenderse de eso.
Dado eso, veamos sus propuestas:
- " Como valor de retorno ": esto no se puede aplicar. Un "valor de retorno" es lo que una función envía a su interlocutor dentro de un solo proceso. En su caso, hay dos procesos.
- " Escrito en un archivo ": recomendaría no hacerlo. Un archivo deja huellas. Una vez que los datos llegan a un medio físico, debe mantener los controles de acceso a este medio siempre . Parece que es mejor mantener todo el contenido en la RAM tanto como sea posible.
- " Encriptación y una toma de corriente ": la encriptación está bien siempre y cuando ya tengas las llaves distribuidas, por lo que estás resolviendo el problema de la gallina y el huevo al afirmar que ya tienes otra. , que no resuelve las cosas. Por otro lado, para un socket que es local para una máquina, puede tener formas de asegurarse de que el proceso en el otro extremo del socket es propiedad de la cuenta esperada; se llama
getpeereid() en sistemas similares a Unix.
- " Comunicaciones entre procesos ": este es un nombre genérico para las formas en que dos procesos se comunican entre sí, e incluye sockets locales. La elección es grande (y muy dependiente del sistema operativo); el punto importante es que puede obtener el ID de usuario efectivo del otro proceso, como
getpeereid() lo hace.
En un sistema similar a Unix, puede usar un socket local, ya sea anónimo (creado con socketpair() ) o nombrado (un "socket de dominio Unix", tal como es); un par de sockets anónimos es posible si sus dos procesos tienen una relación padre-hijo que les permitió intercambiar descriptores de archivos. También puede usar tuberías, también anónimas, oa través de un punto de encuentro basado en archivos (una "tubería con nombre"), en la que el sistema de archivos contiene el área de la reunión, pero los datos permanecen únicamente en la RAM. La memoria compartida SysV, mmap() con MAP_SHARED sobre /dev/zero , ... hay muchas posibilidades, cada una con sus propios métodos para controles de acceso.
En un sistema Windows, las posibilidades son aún más variadas, debido a la larga historia de capas sucesivas de inventiva en este sistema operativo (nunca abandonan nada, son buenos en compatibilidad con versiones anteriores), pero también rediseñan subsistemas completos cada dos años, por lo que los métodos de IPC tienden a acumularse; en 2003, conté con no menos de 9 métodos para eso, y estoy seguro de que ahora hay otros).