Está buscando dos cosas, que RSA puede proporcionar:
- Desea cifrar un mensaje para que no pueda leerse sin la clave privada del destino.
- Esto es el cifrado de la clave pública del destino. ¡Ya estás haciendo esto!
- Desea que el destino pueda verificar que usted, la fuente aprobada, es de hecho quien envió el mensaje.
- Esto es firmar y verificar. Debe firmar el mensaje con su clave privada (de la fuente) cuando lo esté cifrando a la clave pública del destino. Luego, el destino utiliza su clave pública (de la fuente) para verificar quién envió el mensaje.
Un ejemplo de uso de GPG para hacer esto desde un archivo por lotes (es decir, comandos automatizados: DEBE tener un par de claves RSA para nada más que esto, ya que la frase de contraseña es vulnerable en el archivo por lotes). Si tiene comandos de envío humanos, NO deben usar el argumento --passphrase; ¡Pídales que lo ingresen en su software para que no sea vulnerable!
gpg --batch --encrypt --sign --local-user "Your own private key <[email protected]>" --passphrase "Put your private key passphrase here" --recipient "DestinationKey <their email>" --output "test.command.gpg" "test.command"
Por supuesto, deberá asegurarse de que el destino haya verificado el mensaje y que la clave de firma sea la correcta.
Otra referencia es ¿Cuál es la diferencia? entre el cifrado y el inicio de sesión en cifrado asimétrico? .
EDITADO PARA AGREGAR: en cuanto a las alternativas a RSA para el cifrado asimétrico, las dos más comunes que conozco son DSA (basadas en logaritmos discretos, y trate de usar a | p | > = 2048 y a | q | > = 224, al igual que usaría al menos 2048 bits para su clave RSA) y EC (Curva elíptica - tenga mucho cuidado con la curva que elija - las curvas 25519 parecen estar bien consideradas hasta ahora, al menos 256 bits) variantes como ECDSA (algoritmo de firma digital de curva elíptica. Consulte Firmas: RSA comparado a ECDSA y RSA frente a DSA para claves de autenticación de SSH para referencias.