Tengo una situación en la que necesito OTP basada en el tiempo.
Pero la mayoría de los ejemplos y casos que he visto utilizan la misma clave para crear y verificar otp.
Pero necesito algo diferente. Quiero crear OTP usando una clave pública, para que solo pueda ser verificada / desencriptada usando solo una clave privada.
¿Hay algún método como este?
Tengo una situación en la que necesito OTP basada en el tiempo.
Primero, recordemos la base de la OTP basada en el tiempo (o) OTP sincronizada en el tiempo. Un TOTP utiliza el TIEMPO (reloj en tiempo real) del cliente en el proceso de generación de OTP. Por lo tanto, es seguro decir que el factor "tiempo" es una clave pública y una clave privada.
Pero la mayoría de los ejemplos y casos que he visto utilizan la misma clave para crear y verificar otp
Esta consulta contradice completamente el concepto TOTP, corrígeme si me equivoco. Más tarde, afirma que necesita algo diferente. Si entendí esto correctamente, quiere que se genere la OTP usando el Tiempo del cliente, El servidor conoce la hora local del cliente ... De esta manera la OTP generada por el usuario (ingresada en cliente) es autenticado por el servidor. Pero desea que se verifique con una clave privada que no es más que la sincronización del servidor de la hora local del cliente. Por lo tanto, deje de referir la clave pública / clave privada con TOTP como
editar: (después de leer los comentarios) El servidor debe tener una sincronización con la hora local del cliente, o el concepto TOTP falla ... No puedo enfatizar los hechos más allá de esto.
En caso de que esté hablando de One Time Password , hay una razón simple por la cual TOTP-Algorithms está usando una clave simétrica en el cliente / dispositivo y en el lado del servidor.
Si echas un vistazo a HOTP-TOTP (RFC6238), se deriva de HOTP-OTP (RFC4226), el algoritmo OTP basado en eventos. Esto se especificó en 2005. El primer teléfono inteligente llegó en 2007.
¿Y qué? Los algoritmos OTP están diseñados para funcionar con dispositivos de hardware. Estos dispositivos de hardware tienen una pantalla, de modo que el usuario puede ingresar la contraseña de un solo uso. Durante la generación de la contraseña de un solo uso, el RFC define un método de truncamiento, de modo que el usuario realmente puede ingresar un conjunto limitado de caracteres. La salida de HMAC-SHA1 es un código hexadecimal de 20 bytes. Nadie quiere ingresar esto como una contraseña de un solo uso.
Para poder realizar una criptografía asimétrica, no puede utilizar ninguna función de truncamiento. De lo contrario, la clave pública no podrá verificar la firma. La clave privada no podrá descifrar el mensaje. Los datos a transferir con claves asimétricas serían mucho más grandes: 1024 bits, 2048 bits ... Nuevamente, el usuario tendría que ingresar manualmente una contraseña de un solo uso muy larga.
Bueno, si el cliente transmite estos datos electrónicamente, no tendría que truncarlos. Pero de nuevo, no estamos hablando de contraseñas de un solo uso, sino de criptografía de clave puble o autenticación basada en certificado de cliente.
Al final, todo se trata de legibilidad humana y truncamiento .
Lea otras preguntas en las etiquetas encryption one-time-password totp