La vinculación de claves criptográficas a identidades ha sido un problema desde la introducción de la tecnología. El desafío consiste en proporcionar y mantener un mapeo públicamente disponible y consistente entre identidades y claves públicas (a las que esas identidades tienen la clave privada). Sin dicho mapeo, los mensajes que se pretenden mantener en secreto pueden salir mal, a veces con resultados desastrosos. Este mismo desafío existe en web3.

Actualmente existen tres posibles soluciones. Los dos enfoques clásicos son un directorio de clave pública y la encriptación basada en la identidad. El tercero es la encriptación basada en el registro, que hasta hace poco era completamente teórica. Los tres enfoques ofrecen diferentes compensaciones entre anonimato, interactividad y eficiencia, que pueden parecer claras al principio, pero el entorno de la cadena de bloques introduce nuevas posibilidades y restricciones. El objetivo de esta publicación, entonces, es explorar este espacio de diseño y comparar estos enfoques cuando se implementan en una cadena de bloques. Cuando los usuarios necesitan transparencia y anonimato en la cadena, un esquema práctico de encriptación basada en el registro es el claro ganador, superando la fuerte suposición de confianza de la encriptación basada en la identidad, pero a un costo.

Los Tres Enfoques en Breve

El enfoque clásico para vincular claves criptográficas a identidades es una infraestructura de clave pública (PKI), con un directorio de claves públicas en su corazón. Este enfoque requiere que un remitente potencial interactúe con un tercero de confianza (el mantenedor del directorio o autoridad de certificación) para enviar mensajes. Además, en el entorno web2, mantener este directorio puede ser costoso, tedioso y ...propenso a errores, y los usuarios corren el riesgo de abuso por la autoridad de certificación.

Los criptógrafos han sugerido alternativas para evitar los problemas con los PKI. En 1984, Adi Shamir sugirióLa encriptación basada en la identidad (IBE), en la cual el identificador de una parte - número de teléfono, correo electrónico, nombre de dominio ENS - sirve como clave pública. Esto elimina la necesidad de mantener un directorio de claves públicas pero conlleva el costo de introducir un tercero de confianza (el generador de claves). Dan Boneh y Matthew Franklin dieron la primera construcción práctica de IBEen 2001, pero IBE no ha recibido una adopción generalizada excepto en ecosistemas cerrados como corporativos o implementaciones gubernamentalesquizás debido a la fuerte suposición de confianza. (Como veremos a continuación, esta suposición puede ser mitigada parcialmente al confiar en un cuórum de partes confiables, lo cual una cadena de bloques puede facilitar fácilmente.)

Una tercera opción, encriptación basada en registro (RBE), erapropuesto en 2018. RBE mantiene la misma arquitectura general que IBE, pero reemplaza el generador de claves de confianza con un "curador de claves" transparente que solo realiza cálculos en datos públicos (específicamente, acumula claves públicas en una especie de "resumen" disponible públicamente). La transparencia de este curador clave hace que la configuración de la cadena de bloques, donde un contrato inteligente puede desempeñar el papel del curador, sea un ajuste natural para RBE. La EBR fue teórica hasta 2022, cuando mis coautores y yo introdujimos el primera construcción de RBE prácticamente eficiente.

Evaluando los compromisos

Este espacio de diseño es complejo, y comparar estos esquemas requiere tener en cuenta muchas dimensiones. Para simplificar las cosas, haré dos suposiciones:

1. Los usuarios no actualizan ni revocan sus claves.
2. El contrato inteligente no utiliza ningún servicio de disponibilidad de datos fuera de la cadena (DAS) o datos de blob.

Discutiré al final cómo cada una de estas consideraciones adicionales podría afectar nuestras tres soluciones potenciales.

Directorio de Clave Pública

Resumen: Cualquiera puede agregar una entrada (id, pk) a una tabla en cadena (el directorio) llamando al contrato inteligente, siempre que el ID aún no haya sido reclamado.

Un PKI descentralizado es básicamente un contrato inteligente que mantiene un directorio de identidades y sus claves públicas correspondientes. Por ejemplo, el Registro de Servicio de Nombres Ethereum (ENS)mantener un mapeo de nombres de dominio ("identidades") y sus metadatos correspondientes, incluidas las direcciones a las que resuelven (de cuyas transacciones se puede derivar una clave pública). Un PKI descentralizado proporcionaría una funcionalidad aún más simple: la lista mantenida por el contrato solo almacenaría la clave pública correspondiente a cada ID.

Para registrarse, un usuario genera un par de claves (o utiliza un par de claves generado previamente) y envía su ID y clave pública al contrato (quizás junto con algún pago). El contrato comprueba que el ID aún no se ha reclamado y, si no es así, agrega el ID y la clave pública al directorio. En este punto, cualquiera puede cifrar un mensaje a un usuario registrado solicitando al contrato la clave pública correspondiente a un ID (si el remitente ha cifrado algo a este usuario antes, no tiene que volver a solicitar el contrato). Con la clave pública, el remitente puede cifrar su mensaje como de costumbre y enviar el texto cifrado al destinatario, que puede utilizar la clave secreta correspondiente para recuperar el mensaje.

Veamos las propiedades de este método.

En el lado negativo del libro mayor:

• No es conciso. El directorio completo de claves debe almacenarse en la cadena para que esté siempre disponible para todos (recuerda, por ahora asumimos que no hay DAS). Para los ~900K nombres de dominio únicos registrados en ENS en el momento de escribir esto, esto significa casi 90 MB de almacenamiento persistente. Las partes registradas deben pagar por el almacenamiento que ocupa su entrada, alrededor de 65K gas (actualmente aproximadamente $1 - ver la evaluación de rendimiento a continuación).
• Encriptación algo interactiva. El remitente necesita leer la cadena para recuperar la clave pública de un usuario, pero solo si es la primera vez que el remitente está encriptando un mensaje para ese usuario en particular. (Recuerda, estamos suponiendo que los usuarios no actualizan ni revocan sus claves).
• No es anónimo para el remitente. Cuando recuperas la clave pública de alguien, te vinculas a ti mismo con el destinatario, lo que indica que tienes algún tipo de relación con ellos. Imagina, por ejemplo, que recuperas la clave pública de WikiLeaks: esto podría generar sospechas de que estás filtrando documentos clasificados. Este problema podría mitigarse con "tráfico de cobertura" (recuperar un gran lote de claves, la mayoría de las cuales no tienes la intención de usar) o de manera similar ejecutando un nodo completo, o con recuperación de información privada (PIR).

En el lado positivo:

• Desencriptación no interactiva. Los usuarios descifran los mensajes con su clave secreta almacenada localmente, por lo que no requiere interacción.
• Transparente. La lista de usuarios y claves es completamente pública, por lo que cualquier persona puede verificar si fueron registrados correctamente.
• Conjunto de ID arbitrarios. El dominio de los ID no está limitado a priori por la construcción; en teoría, el ID puede ser un cadena arbitraria (hasta las restricciones impuestas por la implementación y el almacenamiento específicos del contrato).

¿Cuándo podría querer usar un directorio de clave pública? Un directorio de clave pública descentralizado es fácil de configurar y administrar, por lo que es una buena elección básica. Sin embargo, si los costos de almacenamiento o la privacidad son una preocupación, una de las otras opciones a continuación puede ser una mejor elección.

(Umbral) Cifrado Basado en Identidad (IBE)

Resumen: La identidad de un usuario es su clave pública. Se necesita un tercero o terceros de confianza para emitir claves y mantener un secreto maestro (puerta trasera) durante toda la vida del sistema.

En IBE, un usuario no genera su propio par de claves, sino que se registra con un generador de claves de confianza. El generador de claves tiene un par de claves "maestro" (msk, mpk en la figura). Dado el ID de un usuario, el generador de claves usa la clave secreta maestra msk y el ID para calcular una clave secreta para el usuario. Esa clave secreta debe comunicarse al usuario a través de un canal seguro (que puede establecerse con protocolo de intercambio de claves).

IBE optimiza la experiencia del remitente: descarga la clave pública del generador de claves una vez, después de lo cual puede encriptar un mensaje a cualquier ID utilizando el propio ID. La desencriptación también es sencilla: un usuario registrado puede utilizar la clave secreta emitida por el generador de claves para desencriptar el texto cifrado.

La clave secreta maestra del generador de claves es más persistente que el "desechos tóxicos" generados por las ceremonias de configuración de confianzausado para algunos SNARKs. El generador de claves lo necesita para emitir nuevas claves secretas, por lo que el generador de claves no puede borrarlo después de configurar la forma en que lo hacen los participantes en las ceremonias de SNARK. También es una pieza peligrosa de información. Cualquiera con el msk puede descifrar todos los mensajes enviados a cualquier usuario en el sistema. Esto significa que hay un riesgo constante de exfiltración con consecuencias catastróficas.

Incluso si el msk se mantiene seguro, cada usuario que se registra en el sistema necesita confiar en el generador de claves para que no lea sus mensajes, ya que el generador de claves puede guardar una copia de la clave secreta del usuario o volver a calcularla a partir de msk en cualquier momento. Incluso podría ser posible que el generador de claves emita una clave secreta defectuosa o "restringida" al usuario que descifre todos los mensajes excepto algunos prohibidos según lo determine el generador de claves.

Esta confianza puede distribuirse entre un quórum de generadores de claves, de modo que un usuario solo necesita confiar en un número umbral de ellos. En ese caso, un pequeño número de generadores de claves maliciosos no puede recuperar claves secretas o calcular claves incorrectas, y un atacante tendría que infiltrarse en varios sistemas para robar el secreto maestro completo.

Si los usuarios están de acuerdo con esta suposición de confianza, (umbral) IBE viene con muchos beneficios:

• Almacenamiento constante / mínimo en la cadena. Solo se necesita almacenar en la cadena la clave pública maestra (un solo elemento de grupo). Esto es mucho menos que el almacenamiento requerido por un directorio de claves públicas en la cadena. Para la encriptación IBE Boneh-Franklin sobre la curva BN254, esto significa agregar 64 bytes de almacenamiento en la cadena persistente una vez durante la fase de configuración, lo que requiere que el servicio gaste solo 40K gas.
• Cifrado no interactivo. Un remitente solo necesita la clave pública maestra (que descarga una vez al principio) y el ID del destinatario para cifrar un mensaje. Esto contrasta con el directorio de claves públicas, donde necesitaría recuperar una clave para cada nuevo usuario con el que desea comunicarse.
• Descifrado no interactivo. De nuevo, los usuarios utilizan sus claves secretas almacenadas localmente para descifrar mensajes.
• Remitente-anónimo. El remitente no necesita recuperar ninguna información por destinatario de la cadena. En comparación, en el caso de un registro de clave pública, el remitente tiene que interactuar con el contrato de una manera que depende del destinatario.
• Conjunto de ID arbitrario. Al igual que en el registro de clave pública, los IDs pueden ser cadenas arbitrarias.

¡Pero!

• Fuerte suposición de confianza. A diferencia del registro de clave pública, donde los usuarios generan sus propias claves, IBE requiere una parte de confianza o un quórum de partes con un secreto maestro (puerta trasera) para emitir claves. El secreto maestro debe mantenerse durante toda la vida del sistema y puede comprometer todos los mensajes de los usuarios registrados si alguna vez se filtra o se usa incorrectamente.

¿Cuándo podrías querer usar (umbral) IBE? Si hay un tercero o terceros de confianza disponibles y los usuarios están dispuestos a confiar en ellos, IBE ofrece una opción mucho más eficiente en cuanto a espacio (y por lo tanto más económica) en comparación con un registro de claves en cadena.

Encriptación basada en registro (RBE)

Resumen: Al igual que en IBE, la identidad de un usuario sirve como su clave pública, pero el tercero o el quórum de confianza se reemplaza por un acumulador transparente (denominado "curador de claves").

En esta sección, discutiré la construcción eficiente de RBE a partir de mi papel, ya que a diferencia de lo que yo sé, solo otra construcción prácticaActualmente se puede implementar en una cadena de bloques (basada en pares en lugar de en retícula). Cuando digo "RBE", me refiero a esta construcción en particular, aunque algunas afirmaciones podrían ser ciertas para RBE en general.

En RBE, un usuario genera su propio par de claves y calcula algunos "valores de actualización" (a en la figura) derivados de la clave secreta y la cadena de referencia común (CRS). Aunque la presencia de un CRS significa que la configuración no es completamente desconfiada, el CRS es un powers-of-tauconstrucción, que puede sercalculado de forma colaborativa en la cadenay es seguro siempre y cuando haya una única contribución honesta.

El contrato inteligente se configura para un número esperado de usuarios N, agrupados en cubos. Cuando un usuario se registra en el sistema, envía su ID, clave pública y valores de actualización al contrato inteligente. El contrato inteligente mantiene un conjunto de parámetros públicos pp (distintos del CRS), que pueden considerarse como un "compendio" sucinto de las claves públicas de todas las partes registradas en el sistema. Cuando recibe una solicitud de registro, realiza una comprobación de los valores de actualización y multiplica la clave pública en el cubo adecuado de pp.

Los usuarios registrados también deben mantener alguna información auxiliar localmente, que utilizan para ayudar con la desencriptación y que se agrega cada vez que un nuevo usuario se registra en su mismo grupo. Pueden actualizar esto ellos mismos monitoreando la cadena de bloques para las registraciones en su grupo, o el contrato inteligente puede ayudar manteniendo una lista de los valores de actualización que recibió de las registraciones más recientes (digamos, en la última semana), que los usuarios pueden extraer periódicamente (al menos una vez a la semana).

Los remitentes de este sistema descargan el CRS una vez y, ocasionalmente, descargan la versión más reciente de los parámetros públicos. En el caso de los parámetros públicos, lo único que importa desde el punto de vista del remitente es que incluyan la clave pública del destinatario previsto; No tiene que ser la versión más actualizada. A continuación, el remitente puede utilizar el CRS y los parámetros públicos, junto con el ID del destinatario, para cifrar un mensaje al destinatario.

Al recibir un mensaje, el usuario verifica su información auxiliar almacenada localmente en busca de un valor que cumpla con alguna condición. (Si no encuentra ninguno, significa que necesita obtener una actualización del contrato). Utilizando este valor y su clave secreta, el usuario puede descifrar el texto cifrado.

Claramente, este esquema es más complejo que los otros dos. Pero requiere menos almacenamiento en cadena que el directorio de clave pública, evitando al mismo tiempo la fuerte suposición de confianza de IBE.

• Parámetros sucintos. El tamaño de los parámetros que se almacenarán en la cadena es sublineal en el número de usuarios. Esto es mucho más pequeño que el almacenamiento total requerido para un directorio de clave pública (lineal en el número de usuarios), pero aún no es constante y, por lo tanto, es peor en comparación con IBE.
• Encriptación algo interactiva. Para enviar un mensaje, el remitente necesita una copia de los parámetros públicos que contienen al destinatario previsto. Esto significa que necesita actualizar los parámetros en algún momento después de que un destinatario previsto se registre, pero no necesariamente para cada destinatario previsto que se registre, ya que una actualización podría incluir las claves de varios destinatarios. En general, el envío de mensajes es más interactivo que IBE pero menos interactivo que un directorio.
• Descifrado algo interactivo. Al igual que en el caso del cifrado, el destinatario necesita una copia de la información auxiliar que "coincida" con la versión de los parámetros públicos utilizados para el cifrado. Más específicamente, tanto el parámetro público como los cubos auxiliares se actualizan cada vez que un nuevo usuario se registra en ese cubo, y el valor a capaz de descifrar un texto cifrado es el correspondiente a la versión pp utilizada para cifrar. Al igual que las actualizaciones de parámetros públicos, un usuario puede decidir recuperar las actualizaciones auxiliares solo periódicamente, excepto cuando se produce un error en el descifrado. A diferencia de las actualizaciones de parámetros públicos, la recuperación de actualizaciones auxiliares con más frecuencia no filtra información de forma inherente.
• Remitente-anónimo. Al igual que en el caso del directorio, el remitente puede encriptar un mensaje completamente por sí solo (siempre que tenga parámetros actualizados) sin consultar información específica del destinatario. La información leída de la cadena, cuando sea necesario, es independiente del destinatario previsto. (Para reducir la comunicación, el remitente podría solicitar solo un cubo de pp específico, filtrando información parcial).
• Transparente. Aunque el sistema debe configurarse mediante una ceremonia de configuración de confianza (potencialmente distribuida y/o administrada externamente) que genere un CRS perforado, no depende de ninguna parte o quórum de confianza una vez que se ha completado la configuración: aunque depende de un tercero coordinador (el contrato), es completamente transparente y cualquiera puede ser un coordinador o comprobar que se está comportando honestamente confirmando sus transiciones de estado (por eso puede serlo). implementado como un contrato inteligente). Además, los usuarios pueden solicitar una prueba sucinta de (no) membresía para verificar que ellos (o cualquier otra persona) están registrados/no registrados en el sistema. Esto contrasta con el caso de la IBE, en el que es difícil para la parte o partes de confianza demostrar realmente que no revelaron en secreto una clave de descifrado (a sí mismos haciendo una copia secreta o a otra persona). El directorio de clave pública, por otro lado, es totalmente transparente.
• Conjunto de ID restringido. He descrito una versión 'básica' de la construcción RBE. Para determinar de manera transparente en qué cubeta cae un ID, los IDs deben tener un orden público y determinista. Los números de teléfono simplemente se pueden ordenar, pero ordenar cadenas arbitrarias es difícil de manejar, si no imposible, ya que el número de cubetas podría ser extremadamente grande o ilimitado. Esto podría ser mitigado ofreciendo un contrato separado que calcule dicho mapeo o adoptando el enfoque de cuckoo-hashing propuesto en este trabajo de seguimiento.

Con extensiones:

• Destinatario anónimo. El esquema se puede ampliar para que los textos cifrados no revelen la identidad del destinatario.

¿Cuándo podría querer usar RBE? RBE utiliza menos almacenamiento en cadena que un registro en cadena y, al mismo tiempo, evita los supuestos de confianza sólida requeridos por IBE. En comparación con un registro, RBE también ofrece mayores garantías de privacidad al remitente. Sin embargo, dado que RBE acaba de convertirse en una opción viable para la administración de claves, aún no estamos seguros de qué escenarios se beneficiarían más de esta combinación de propiedades. Por favor házmelo sabersi tienes alguna idea.

Comparación de rendimiento

Estimé los costos (al 30 de julio de 2024) de implementar cada uno de estos tres enfoques en la cadena de bloques. este cuaderno de Colab. Los resultados para una capacidad del sistema de ~900K usuarios (la cantidad de nombres de dominio únicos registrados en ENS en el momento de escribir este artículo) se muestran en la tabla a continuación.

PKI no tiene costo de configuración y tiene un bajo costo de registro por usuario, mientras que IBE tiene un pequeño costo de configuración y un registro prácticamente gratuito por usuario. RBE tiene un costo de configuración más alto y también un costo de registro inesperadamente alto, a pesar del bajo almacenamiento en cadena requerido.

La mayor parte del costo de registro (asumiendo que el cálculo se realiza en L2) proviene del hecho de que las partes deben actualizar un fragmento de los parámetros públicos en el almacenamiento persistente, lo que se suma a un alto costo de registro.

Aunque RBE es más costoso que las alternativas, este análisis muestra que puede ser implementado de manera factible en la red principal de Ethereum hoy en día, sin las posibles y arriesgadas suposiciones de confianza de PKI o IBE. Y esto es antes de optimizaciones como la implementación de múltiples instancias más pequeñas (y por lo tanto más baratas) o el uso de datos de blob. Dado que RBE tiene ventajas sobre el directorio de claves públicas e IBE en forma de mayor anonimato y disminución de suposiciones de confianza, podría ser atractivo para aquellos que valoran la privacidad y las configuraciones sin confianza.

Noemi Glaeser es candidata a doctorado en Ciencias de la Computación en la Universidad de Maryland y el Instituto Max Planck de Seguridad y Privacidad y fue pasante de investigación en a16z crypto durante el verano del 23. Ha recibido la beca de investigación de posgrado de la NSF y anteriormente fue pasante de investigación en NTT Research.

Apéndice: Consideraciones adicionales

Tratando las actualizaciones/revocaciones de claves

En el caso de un directorio de clave pública, el manejo de actualizaciones y revocaciones de claves es simple: para revocar una clave, una parte solicita al contrato que la borre del directorio. Para actualizar una clave, la entrada (id, pk) se sobrescribe con una nueva clave (id, pk’).

Para la revocación en IBE, Boneh y Franklin sugirieron que los usuarios actualicen periódicamente sus claves (por ejemplo, cada semana) y que los remitentes incluyan el período de tiempo actual en la cadena de identidad al encriptar (por ejemplo, 'Bob '). Debido a la naturaleza no interactiva de la encriptación, los remitentes no tienen forma de saber cuándo un usuario revoca su clave, por lo que algunas actualizaciones de periodo son inherentes. Boldyreva, Goyal y Kumar dieron una mecanismo de revocación más eficiente Basado en IBE "difusa"que requiere dos claves para el descifrado: una clave de “identidad” y una clave adicional de “tiempo”. De esta manera, solo la clave de tiempo debe actualizarse regularmente. Las claves de tiempo de los usuarios se acumulan en un árbol binario, y un usuario puede utilizar cualquier nodo a lo largo del camino (en el caso básico, solo se necesita la raíz y es la única parte que publica el generador de claves). La revocación de claves se logra al dejar de publicar actualizaciones para un usuario en particular (eliminando nodos a lo largo del camino de ese usuario del árbol), en cuyo caso el tamaño de la actualización aumenta pero nunca es más que logarítmico en el número de usuarios.

Nuestra eficiente construcción de RBE no consideró las actualizaciones y revocaciones, una trabajo de seguimientoproporciona un compilador que puede "actualizar" nuestro esquema para agregar estas funcionalidades.

Moviendo datos fuera de la cadena con DAS

Utilizar una solución de disponibilidad de datos (DAS) para mover el almacenamiento en cadena fuera de la cadena solo afectaría el cálculo del directorio de clave pública y RBE, reduciéndolos ambos a la misma cantidad de almacenamiento en cadena. RBE mantendría la ventaja de ser más privado para el remitente, ya que aún evita filtrar la identidad del destinatario a través de patrones de acceso. IBE ya tenía un almacenamiento mínimo en cadena y no se beneficiaría de DAS.

Aviso legal:

1. Este artículo es reproducido de [a16zcrypto], Todos los derechos de autor pertenecen al autor original [ Noemi Glaeser]. Si hay objeciones a esta reimpresión, por favor contactar a la Gate Learnequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.