Fuente: Noemi Glaeser, a16z crypto
En Llave pública Criptografía, siempre ha habido un problema, que es cómo asociar correctamente Llave secreta (encriptación como Llave pública) con una identidad específica (como una persona u organización). La clave de este problema radica en tener una forma pública y consistente de mostrar la relación entre la identidad y Llave pública, para que todos puedan usar estas Llave pública para encriptar la información con confianza.
Si no hay una relación clara como esta, otros pueden no poder determinar a quién pertenece realmente una Llave pública, lo que podría resultar en el envío de información de encriptación a la persona equivocada, lo que podría llevar a una filtración de información u otras consecuencias graves. En Web3, este problema sigue existiendo.
Para los problemas mencionados anteriormente, actualmente existen tres soluciones: Directorio de Claves Públicas, encriptación basada en la identidad (IBE) y encriptación basada en registros (RBE). Estos tres métodos tienen sus propias ventajas en anonimato, interactividad y eficiencia. Por ejemplo, IBE requiere una base de confianza sólida, pero en ciertos casos, IBE tiene un mejor desempeño en anonimato y eficiencia. Este artículo tiene como objetivo explorar la aplicación de estos tres métodos en la cadena de bloques y comparar sus ventajas y desventajas.
Tres métodos
Generalmente, un método común para asociar la encriptación de la Llave secreta con la información de identidad es mediante el uso de la infraestructura de clave pública (PKI), donde una parte central es un directorio de Llave pública. En este método, la persona que envía la información debe interactuar con un tercero de confianza (generalmente una autoridad de certificación que mantiene este directorio) para enviar la información encriptada.
Sin embargo, en el entorno de Web2, mantener este directorio de Llave pública requiere altos costos y operaciones tediosas. Además, los usuarios también enfrentan el riesgo de abuso de poder por parte de las autoridades de certificación.
Se propusieron algunas alternativas por parte de los criptógrafos para abordar los problemas en la infraestructura de clave pública (PKI). En 1984, Adi Shamir propuso la encriptación basada en identidad (IBE), donde la identidad de una de las partes (como un número de teléfono, correo electrónico o un nombre de dominio ENS) se puede utilizar directamente como clave pública. Este enfoque elimina la necesidad de mantener un directorio de claves públicas, pero introduce un nuevo problema: se debe confiar en un generador de claves secretas de confianza para generar la clave privada.
En 2001, Dan Boneh y Matthew Franklin propusieron la primera construcción práctica de IBE, pero esta tecnología no se ha adoptado ampliamente, principalmente se usa en algunos ecosistemas cerrados, como entornos de implementación empresarial o gubernamental. Una de las razones por las que IBE no se usa ampliamente puede ser su dependencia de una suposición de confianza fuerte, es decir, confiar en un tercero para generar la Llave secreta.
Sin embargo, como se discutirá en este artículo, este problema de confianza puede resolverse mediante la dependencia de un más largo de confianza (es decir, un grupo de participantes que forman un número legal) y la tecnología blockchain puede implementar esto fácilmente.
Ventajas y desventajas
Al comparar estos esquemas de encriptación, es necesario considerar muchos factores diferentes, y hago dos suposiciones al respecto:
Los usuarios no actualizarán ni revocarán su Llave secreta: esto significa que en la discusión se supone que la Llave secreta de cada usuario es fija y no cambia.
Contrato inteligente no utiliza ningún servicio de disponibilidad de datos off-chain (DAS) o datos blob: es decir, se supone que Contrato inteligente depende completamente de los datos on-chain, sin implicar servicios de datos fuera de la cadena o almacenamiento adicional de datos.
![]()
Directorio de Clave Pública
Cualquier persona puede agregar una entrada (id, pk) no utilizada al directorio on-chain llamando al contrato inteligente.
![]()
La PKI (Infraestructura de Clave Pública) descentralizada se refiere a un directorio mantenido a través de contratos inteligentes que vincula una identidad (ID) con su correspondiente clave pública. Este directorio es público y no depende de terceros centralizados. Por ejemplo, en el caso de ENS, se mantiene un mapeo entre un nombre de dominio (es decir, identidad) y metadatos relacionados, incluyendo la dirección (DIRECCIÓN) asociada a ese nombre de dominio (la cual se puede inferir de las transacciones asociadas a esa dirección). ENS es un sistema más complejo, que no solo registra claves públicas, sino que también almacena otros metadatos. La funcionalidad de la PKI descentralizada es relativamente más simple: el contrato inteligente solo necesita mantener una lista que registre cada identidad junto con su correspondiente clave pública.
Cuando un usuario desea registrarse con una identidad, primero necesita generar un par de Llave secreta (Llave pública y Llave privada), o usar una Llave secreta generada previamente, y enviar su ID de identidad y Llave pública a Contrato inteligente (posiblemente pagando una tarifa), el Contrato inteligente verificará si ese ID ya está registrado por otra persona. Si no está ocupado, el Contrato inteligente agregará ese ID y Llave pública al directorio. Una vez completado el registro, cualquier persona puede obtener la Llave pública correspondiente a un ID consultando al Contrato inteligente, para encriptación y enviar mensajes a ese usuario. Si el remitente ya ha encriptado mensajes previamente a este usuario y ya tiene la Llave pública de ese usuario, no necesita solicitar la Llave pública al Contrato inteligente nuevamente. Con la Llave pública, el remitente puede encriptar mensajes como de costumbre y luego enviar los mensajes encriptados al destinatario, quien usará la Llave privada correspondiente para descifrar el mensaje y recuperar el texto original.
Veamos las ventajas y desventajas de este método:
Ventajas Desventajas Desencriptación no interactiva: el proceso de desencriptación no requiere interacción con otras partes, el desencriptador puede completar la desencriptación de forma independiente. No conciso (Not succinct): el sistema puede no ser lo suficientemente conciso en algunos aspectos, lo que puede significar una alta complejidad, grandes volúmenes de datos o la necesidad de más recursos. Transparencia: el sistema puede ser transparente en algunos aspectos, lo que significa que las operaciones son públicas y pueden ser revisadas. Encriptación interactiva: el proceso de encriptación puede requerir cierta interacción con otras partes, lo que aumenta la complejidad. ID arbitraria: los usuarios pueden elegir libremente o utilizar cualquier identificación de usuario, sin estar limitados por un formato o regla específica. Remitente no anónimo: la identidad del remitente puede no poder mantenerse completamente anónima en el sistema.
encriptación basada en la identidad (IBE)
La identidad del usuario está representada por su Llave pública, lo que significa que la Llave pública no solo se utiliza para la encriptación, sino también como identificador único del usuario. Sin embargo, este método requiere depender de uno o varios terceros confiables, quienes son responsables de generar y emitir la Llave secreta. Además, estos terceros deben mantener una Llave secreta principal durante todo el ciclo de vida del sistema, la cual podría utilizarse en ciertos casos para descifrar u otras operaciones importantes.
![]()
En el sistema IBE, el usuario no genera un par de llaves pública y privada como en los sistemas de encriptación tradicionales. En cambio, el usuario debe registrarse utilizando un generador de llaves secretas de confianza. El generador de llaves secretas tiene un par de llaves secretas principales (incluyendo la llave privada principal msk y la llave pública principal mpk). Cuando el usuario proporciona su ID, el generador de llaves secretas utiliza la llave privada principal msk y el ID del usuario para calcular una llave privada exclusiva para el usuario. La llave privada generada debe ser entregada al usuario a través de un canal seguro, generalmente establecido utilizando un protocolo de intercambio de llaves secretas.
Para el remitente, el sistema IBE simplifica el proceso de encriptación. El remitente solo necesita descargar una vez la clave pública principal (mpk) del generador de claves secretas, y luego puede usar la ID para encriptar el mensaje. Para el destinatario, la descifrado también es simple. Los usuarios registrados pueden usar la llave privada que les proporciona el generador de llaves secretas para descifrar el texto cifrado recibido.
La Llave privada generadora de claves (msk) debe ser guardada a largo plazo, ya que se requiere generar constantemente nuevas Llave privada de usuario durante la operación del sistema. Esto es diferente a algunos sistemas SNARK que se generan durante el proceso de configuración de confianza, pero se pueden eliminar después de la configuración. En el sistema IBE, la Llave privada principal no se puede eliminar después de la inicialización, como en SNARK.
Incluso si el principal Llave privada (msk) se guarda correctamente, cada usuario registrado aún necesita confiar en que el generador de claves no leerá sus mensajes. Esto se debe a que el generador de claves puede guardar en cualquier momento una copia de la Llave privada del usuario, o utilizar el principal Llave privada para volver a calcular la Llave privada del usuario.
El generador de Llave secreta también puede proporcionar a los usuarios una Llave privada defectuosa o limitada, que puede descifrar la mayoría de los mensajes pero no puede descifrar mensajes específicos establecidos por el generador de Llave secreta. Esto significa que el generador de Llave secreta tiene la capacidad de manipular la capacidad de descifrado de los usuarios, lo que puede resultar en cierto grado de control o restricción de las comunicaciones de los usuarios.
Ventajas y desventajas del almacenamiento on-chain: El sistema requiere una cantidad mínima o constante de almacenamiento en bloquear-chain, que no aumenta con el tiempo. Suposición de confianza sólida: El sistema depende de uno o varios terceros de confianza, lo que significa que se necesita una fuerte confianza en estos terceros. Si estos terceros son comprometidos o no son confiables, la seguridad del sistema se verá amenazada. Encriptación no interactiva: El proceso de encriptación no requiere interacción con otras partes, el remitente puede completar la encriptación de forma independiente. Anonimato del remitente: El sistema puede mantener el anonimato del remitente, protegiendo la privacidad. Identificación arbitraria: Los usuarios pueden elegir libremente o utilizar cualquier identificación de identidad, sin restricciones de formato o reglas específicas.
Encriptación basada en registro (RBE)
Al igual que en IBE, en este sistema, la identidad del usuario (por ejemplo, correo electrónico DIRECCIÓN o número de teléfono) actúa directamente como su llave pública. Sin embargo, a diferencia de IBE, este sistema ya no depende de un tercero de confianza o un grupo de quórum para gestionar la llave secreta. En su lugar, este tercero de confianza es reemplazado por un curador de claves.
En esta sección discutiré una forma eficiente de construir RBE, ya que según mi conocimiento esto tiene una ventaja significativa en comparación con otras construcciones prácticas de RBE. Puede ser implementado en la cadena de bloques porque es basado en emparejamientos, en lugar de estar basado en mallas.
![]()
En el sistema RBE, cada usuario genera su propia Llave secreta (que incluye Llave pública y Llave privada). Los usuarios también necesitan calcular algunos valores actualizados (denominados a en el diagrama) basados en su Llave privada y una Cadena de Referencia Pública (CRS). Estos valores actualizados se utilizan para operaciones adicionales en el sistema. La existencia de la Cadena de Referencia Pública (CRS) significa que la configuración del sistema no es completamente desconfiada. Sin embargo, el proceso de generación de CRS utiliza un método de construcción llamado tau de potencia. Este método de construcción puede completarse on-chain a través de la colaboración de múltiples participantes. Si al menos un participante es honesto, esta CRS será segura.
El contrato inteligente ha sido establecido para un número esperado de usuarios N, los cuales están agrupados en diferentes buckets. Cuando un usuario se registra en el sistema, debe enviar su ID de identidad, la llave pública y el valor actualizado al contrato inteligente. El contrato inteligente mantendrá un conjunto de parámetros públicos pp, los cuales son distintos de la cadena de referencia pública (CRS) mencionada anteriormente. Se puede entender pp como un resumen conciso de las llaves públicas de todos los usuarios registrados en el sistema. Después de recibir la solicitud de registro del usuario, el contrato inteligente verifica los valores actualizados para validar su corrección. Una vez validados, el contrato inteligente multiplicará la llave pública del usuario en los buckets correspondientes de pp. Este paso equivale a incluir la llave pública del nuevo usuario en el conjunto de parámetros públicos del sistema para su uso en operaciones futuras.
En el sistema de encriptación basado en registros (RBE), los usuarios necesitan guardar información localmente que les ayudará a descifrar los mensajes. Cuando hay nuevos usuarios registrados en el mismo grupo, esta información debe actualizarse. Los usuarios pueden monitorear la cadena de bloques para actualizar manualmente esta información, o los contratos inteligentes pueden proporcionar información de los usuarios registrados más recientes para que los usuarios puedan obtener estas actualizaciones periódicamente y mantener su información de descifrado actualizada.
En este sistema, el remitente solo necesita hacer dos cosas:
Descarga la Cadena de Referencia Pública (CRS): solo necesitas descargarla una vez, luego no es necesario actualizarla.
Descargar parámetros públicos: los remitentes deben descargar ocasionalmente los parámetros públicos más recientes. Para los remitentes, es importante que estos parámetros públicos contengan la Llave pública del destinatario, sin necesidad de descargar la última versión cada vez, solo es necesario poder encontrar la Llave pública del destinatario.
Luego, el remitente puede encriptar el mensaje y enviarlo al destinatario utilizando el CRS descargado, los parámetros públicos y la identificación del destinatario. Esto significa que el remitente no necesita actualizar los datos con frecuencia, solo asegurarse de que los parámetros públicos contengan la Llave pública del destinatario.
Cuando un usuario recibe un mensaje de encriptación, primero verifica la información auxiliar almacenada localmente para ver si existe algún valor que cumpla ciertas condiciones (por ejemplo, un valor verificado por alguna verificación). Si el usuario no encuentra un valor adecuado en su dispositivo local, significa que necesita obtener la información más reciente de actualización del contrato inteligente. Una vez que el usuario encuentra un valor auxiliar adecuado, puede usar este valor y su propia llave privada para descifrar el texto cifrado recibido y recuperar el mensaje original.
Obviamente, este enfoque es más complejo que los otros dos. Sin embargo, requiere menos almacenamiento en cadena que el directorio de Llave pública y evita la suposición de fuerte confianza de IBE.
Parámetros concisos:
- La relación entre el tamaño de los parámetros almacenados en la cadena y el número de usuarios es sublineal, lo que es mucho menor que el volumen de almacenamiento requerido por el directorio de Llave pública (que es lineal subir), pero aún no es constante, por lo que en este aspecto no es tan eficiente como los sistemas de encriptación basados en identidad (IBE).
encriptación con cierta interactividad:
- Al enviar un mensaje, el remitente necesita una copia de los parámetros públicos que incluya al destinatario objetivo. Esto significa que el remitente debe actualizar estos parámetros en algún momento después del registro del destinatario, pero no es necesario actualizarlos individualmente para cada destinatario, ya que una actualización puede incluir varias Llaves secretas. En general, la interactividad en el envío de mensajes es mayor que en IBE, pero menor que en el uso del catálogo de Llaves públicas.
Una descifrado con cierta interactividad:
- Similar a la encriptación, el receptor necesita una versión de parámetros públicos coincidente con encriptación para obtener información auxiliar. Cuando un nuevo usuario se registra en un grupo, los parámetros públicos y la información auxiliar se actualizan, lo que permite descifrar el valor del Texto cifrado correspondiente a la versión de parámetros públicos utilizada en encriptación. Los usuarios pueden optar por obtener actualizaciones de información auxiliar de forma regular en lugar de actualizarla inmediatamente cada vez, a menos que falle la descifrado. A diferencia de la actualización de parámetros públicos, obtener actualizaciones de información auxiliar de forma más frecuente no revelará información privada.
Remitente anónimo:
- Al igual que con el directorio de Llave pública, el remitente puede encriptar mensajes de forma independiente (siempre y cuando tenga los parámetros más recientes) sin necesidad de consultar información específica relacionada con el destinatario. Cuando el remitente necesita leer información de la cadena (on-chain), esta información no está relacionada con el destinatario objetivo (a menos que el remitente solicite solo un grupo de parámetros específicos, pero esto puede revelar parte de la información).
Transparencia:
- Aunque el sistema necesita ser configurado a través de una configuración de confianza (ya sea distribuida o gestionada externamente) y produce un CRS corregido (Cadena de referencia pública), una vez configurado, ya no depende de ninguna tercera parte de confianza o grupo de arbitraje. Aunque depende de un tercero coordinado (contrato inteligente), este sistema es completamente transparente y cualquiera puede actuar como coordinador o verificar que funcione de manera honesta a través de la validación de transiciones de estado (también por eso puede ser implementado como contrato inteligente). Además, los usuarios pueden solicitar una prueba de membresía (no) concisa para verificar si ellos mismos u otras personas están registradas en el sistema. Esto difiere de los sistemas IBE, en los que es difícil que una tercera parte de confianza demuestre que no han revelado secretamente la llave secreta (por ejemplo, si tienen una copia secreta guardada o la han revelado a otra persona). En contraste, el directorio de llaves públicas es completamente transparente.
Conjunto de ID restringido:
- Esta es la versión básica de RBE construida. Para determinar de manera transparente a qué grupo pertenece un ID, el ID debe tener un orden común y definido. Los números de teléfono pueden ordenarse fácilmente, pero ordenar cualquier cadena puede ser muy complicado o incluso imposible, ya que la cantidad de grupos puede ser muy grande o infinita. Esto se puede mitigar proporcionando un contrato único para calcular este mapeo, o adoptando el método de cuckoo-hashing propuesto en trabajos posteriores para mitigar esta complejidad.
Destinatario anónimo:
- Este método permite que el Texto cifrado no revele la identidad del destinatario.
