Supongo que está creando un protocolo de juguete por diversión, aprenda sobre crypto, diviértase implementando algo, pero comprenda que este esquema de juguetes probablemente sea defectuoso y que si tiene datos confidenciales, debería usarlos. Protocolos revisados, no esquemas de juguetes que se te ocurrieron. (Si no ve las razones para no rodar las suyas propias ).
Primero, RSA solo describe el esquema c = m^e mod N donde usted cifra un mensaje m con una clave pública (N,e) , y descifra con el par de claves privadas (N,d) a través de m = c^d mod N . No debe cifrar su OTP con RSA; será muy ineficiente y hay muchos ataques contra RSA sin el relleno adecuado. Realmente siempre debes usar esquemas de relleno como OAEP (específicamente PKCS # 1v2 ). RSA es costoso para mensajes largos, en la práctica siempre se utiliza el cifrado híbrido. Es decir, usar RSA para cifrar una clave generada aleatoriamente para una función de encriptación simétrica como AES (otras funciones de encriptación están bien, solo elija AES para concretar). Así que Alice envía primero E RSA (RSA-PubKey, OAEP (Random-AES-key)), donde RSA-PubKey = (N, e) y E RSA (RSA -PubKey, m) = m e mod N. Luego envía los datos secretos encriptados AES E AES (Random-AES-Key, Secret-Data), que solo significa que Secret-Data está cifrado con AES y la clave Random-AES generada recientemente. Luego, el receptor primero descifra la clave AES utilizando RSA con la clave privada (N, d) y luego deshace el relleno OAEP, y luego descifra el mensaje utilizando esa clave AES para recuperar los datos secretos.
Dicho esto, sumas de comprobación no deben utilizarse para evitar la manipulación de un mensaje en tránsito. Si un atacante puede adivinar un mensaje, puede calcular la suma de comprobación y, a continuación, manipular el mensaje cifrado para modificar tanto el mensaje como la suma de comprobación. Por ejemplo, si el mensaje se cifró con el modo AES-CTR y el mensaje es m = "Transfer $1000 from Alice to Bob's account." y utiliza el hash MD5 como suma de comprobación h=b2a26c14a029b0a2aadba4fa2ecd32d2 . Eve podría calcular xor entre ese mensaje y m' = "Transfer $9999 from Alice to Eve's account." que tiene la suma de comprobación md5 h' =308b23cb47b0efff365c2593e0a005d7 y luego XOR el mensaje cifrado con m XOR m' y la suma de comprobación cifrada con h XOR h' .
Los Códigos de autenticación de mensajes son la manera de proporcionar integridad de que su mensaje no fue manipulado. Estos son esencialmente sumas de comprobación que se basan intrínsecamente en una clave secreta compartida. Siempre hay una pregunta sobre cómo usar MAC, si debe Encriptar luego MAC - (enviar E(Data) ++ MAC(E(Data) ) o MAC-luego Encriptar (enviar E(data ++ MAC(data)) ) o Encriptar y MAC (enviar E(data) ++ MAC(Data) ), pero Encrypt-then-MAC es la mejor opción de consenso, aunque otros esquemas pueden ser seguros para ciertos sistemas de cifrado .
Hay otros problemas (por ejemplo, generar OTP es bastante costoso y usa mucha entropía, lo que podría ser problemático). Tampoco veo qué es lo que gana el paso OTP en seguridad, por ejemplo, si el paso RSA está comprometido, todos los demás datos también están comprometidos para cualquier persona que escuche a escondidas.
Además, el pad de una sola vez solo tiene seguridad demostrable cuando el pad se usa exactamente una vez. El pad de muchos tiempos es notoriamente débil como c1 XOR c2 = m1 XOR m2. Por ejemplo, supongamos que Eve no puede enviar solicitudes de archivos a Bob, que existe una función de autenticación no revelada que verifica la identidad de Alice a Bob antes de que Bob responda con un archivo cifrado mediante un OTP). Si observa que Alice solicita el archivo 1, al enviar una OTP cifrada de 7 MB (OTP1), puede solicitar el archivo 2 (solo 6 MB) que envía los mismos primeros 6 MB de OTP1. Bob responde luego con el archivo2 XOR OTP1, filtrando a Eva el XOR del archivo1 y el archivo2. Entonces, junto con la OTP que es MAC'd, debe haber un esquema con un nonce aleatorio (generado por el servidor) que debe incluirse con la OTP cifrada, que se verifica (para asegurarse de que la almohadilla cifrada no fue reemplazada por una OTP utilizada anteriormente).