INTfs: Protocolo para compartir archivos encriptados, privados y anónimos distribuidos en la red INT
Autor: Graytrain, 9 de julio de 2019
Artículo original: INTfs — Protocol for encrypted, private and anonymous distributed file sharing in the INT Network
Resumen
La transmisión de datos es una de las funciones principales de IoT. Las decisiones que se tomen dentro de la red dependerán de los datos para hacerlo. Los protocolos existentes para el almacenamiento y la recuperación de datos en una red distribuida son generales en su enfoque y no proporcionan controles de privacidad en el protocolo. IPFS es el líder en este espacio, pero se está centrando en Internet descentralizado. Usando el hash del archivo como la clave solicitante, construir una imagen de quién solicita qué, puede llevar a un colapso del anonimato. INTfs es un enfoque especializado para el almacenamiento descentralizado, que construye un puente entre INT e IPFS, que incorpora un protocolo para la encriptación asimétrica no interactiva, solicitudes de datos cegados y prueba de almacenamiento para la compensación de nodos con la cadena INT como base transaccional.
Introducción
Resumen y Objetivos
IPFS proporciona una base sólida para el alojamiento y la transferencia de datos distribuidos. Se puede usar como una nube personal, protocolo de transferencia de archivos o como el backend de HTTP para un Internet descentralizado. Combina la distribución de archivos BitTorrent con las estructuras de datos Merkle DAG, proporcionando una base confiable y sólida para sistemas de archivos versionados o blockchains. Le permite cargar cualquier archivo, sin importar el formato, y compartirlo o acceder a él por su hash. Debido a que IPFS no requiere la capacidad de leer el archivo, el usuario es libre de cargar archivos encriptados pero no ofrece un marco o sistema de indexación de la clave para hacerlo.
Otros proyectos han intentado utilizar IPFS como su protocolo subyacente para producir un servicio en la nube distribuido, pero nuevamente estas redes dependen de la capacidad técnica de los usuarios para obtener las claves de encriptación y encriptar el archivo ellos mismos antes de cargarlo. Para incentivar la participación de los nodos de almacenamiento en estas redes, introducen su propio token patentado para tasas y recompensas, lo que requiere que los usuarios obtengan este token para utilizar el servicio.
INTfs busca resolver estos problemas proporcionando una infraestructura para indexar las claves de encriptación, encriptar archivos y mensajes, y almacenar datos encima de una red transaccional de activos fijos, INT Chain. Al utilizar la red de nodos existente para el almacenamiento distribuido y el mecanismo de consenso para asegurar el sistema de archivos, garantizar la sincronización y distribuir los costes, podemos proporcionar todos los beneficios de otras redes distribuidas en la nube, de forma económica y sin un token secundario. Esto crea un sistema de archivos distribuido privado y anónimo con una confianza mínima dentro de una red existente.
INT Chain como la Base Transaccional
INT Chain es un blockchain DPoS enfocado a IoT con una infraestructura multicadena heterogénea que permite un alto rendimiento y facilidad de escalado con la adición de subcadenas. La estructura transaccional se basa en cuentas como Ethereum con habilidad de scripting limitada. Como no está estructurado en transacciones basadas en UTXO, permite muchos tipos de transacciones para staking (bloqueo), votar y registrar nodos. Esto crea una estructura abierta para la adición de tipos de transacciones y otros mecanismos para publicar información en blockchain. El mecanismo de consenso DPoS permite un tiempo de bloque de 10 segundos, rotando a través de un grupo de 13 nodos “Thearchy” que actúan como validadores que operan una sola cadena a 2,000 TPS en su estado actual. El plan de INT es aumentar el número de nodos de validación para admitir la adición de subcadenas, con la estructura lógica de cada subcadena definida para dar soporte al caso de uso (por ejemplo, rendimiento de transacciones adicionales, transacciones específicas de dispositivos IoT, contratos inteligentes, transacciones confidenciales, etc.).
Asumimos que el estado actual de INT Chain es la base transaccional y que puede aceptar los formatos de transacción propuestos en este documento, así como la subcadena adicional para almacenar las pruebas asociadas con este protocolo. Los nodos Thearchy asumirían la responsabilidad de almacenar y servir archivos.
Encriptación de datos
La encriptación de datos puede hacerse con claves simétricas o asimétricas. Los esquemas de encriptación asimétrica le permiten encriptar datos con una clave pública, eliminando la necesidad de comunicarse con el destinatario de antemano como lo hacen los esquemas de encriptación simétrica. Los problemas con la encriptación asimétrica son los tiempos de cálculo necesarios para encriptar / desencriptar y el tamaño de las claves requeridas. Las claves simétricas son mucho más pequeñas pero requieren compartir la clave. Lo más práctico es usar un sistema híbrido de encriptación de clave simétrica con encriptación asimétrica para compartir la clave utilizada para encriptar.
El tamaño de la clave es la próxima preocupación. Las claves más pequeñas permiten una gestión de datos más fácil, menores requisitos de hardware, reducen el ancho de banda necesario para la transmisión y reducen el consumo de energía en dispositivos móviles. La criptografía de curva elíptica aporta claves significativamente más cortas para el mismo nivel de seguridad sobre otros sistemas criptográficos como RSA. Para un nivel de seguridad de 128 bits, que es lo suficientemente fuerte para esta aplicación, la longitud de la clave RSA es de 3072 bits, mientras que una clave ECC es de 256 bits.
Esquema de Encriptación Integrada de Curva Elíptica (ECIES)
ECIES es un sistema de encriptación híbrida propuesto por Victor Shoup en 2001 [Shoup01]. Combina un mecanismo de encapsulación de claves (KEM) con un mecanismo de encapsulación de datos (DEM) para proporcionar la velocidad de la encriptación simétrica y la seguridad de la encriptación asimétrica con la eficiencia de la generación de claves de curva elíptica.
Utiliza las siguientes funciones:
- Acuerdo de clave (KA): función utilizada por dos partes para crear un secreto compartido.
- Función de derivación de clave (KDF): función utilizada para crear pares de claves asimétricas.
- Hash: función de resumen.
- Encriptación simétrica (ENC): encriptación con una sola clave para encriptar y desencriptar.
- Código de autenticación de mensaje (MAC): información utilizada para autenticar un mensaje.
Dado que los pares de claves pública-privadas se generarán con anticipación y se publicarán, la parte que envía puede realizar este proceso en su totalidad sin ninguna comunicación entre ellos.
Usando este protocolo, para encriptar y comunicar un mensaje, m:
1. Primero generamos un nuevo par de claves pública-privada llamada clave efímera, representada como parte privada u y clave pública U = u • G.
2. Usando el protocolo de Acuerdo de Clave, creamos un secreto compartido tomando la clave privada efímera y multiplicándola por la clave pública del destinatario, V.
3. Toma la clave secreta compartida, u • V, como dato de entrada para el KDF, siendo la salida una concatenación de la clave MAC, k_mac, y la clave de encriptación, k_ENC.
4. Encripta el mensaje m, utilizando el algoritmo de encriptación simétrica ENC con la clave, k_ENC. El resultado es texto encriptado, c.
5. Use la función MAC con texto cifrado, c, y la clave MAC, k_mac, para producir un tag.
6. Concatena la clave pública efímera, el tag y el texto encriptado (U || tag || c) y envía este criptograma al destinatario.
Para que el destinatario desencripte el mensaje m:
1. Separe el criptograma en sus partes constituyentes, U, tag y c.
2. Use la clave pública efímera recuperada, U, y la clave privada del destinatario, v, para recuperar el secreto compartido, u: v • U = (v · u) • G = u • V
3. Produzca las claves de encriptación y MAC, k_ENC’ y k_mac’, utilizando el KDF en el mismo proceso que el paso 3 anterior.
4. Use la función MAC con texto encriptado del criptograma, c, y la llave MAC, k_mac’, para producir tag’. Si tag’ no es igual a tag, se produce un error ya que la verificación MAC falló. Si es igual, sigue.
5. Descifra el texto cifrado c utilizando el algoritmo de encriptación simétrica ENC con la clave k_ENC. El resultado es el mensaje deseado m.
Estándares
Se encuentra que los siguientes estándares producen una encriptación fuerte con las velocidades de computación más rápidas [Mart15].
Para las operaciones de curva elíptica para la generación de clave efímera en el Acuerdo de Clave, se utilizará la curva elíptica x sobre el campo finito de extensión binaria GF(2 m) [CPPbench]. Esto es beneficioso para las implementaciones de hardware, ya que sus operaciones, como la suma y la multiplicación, pueden realizarse mediante las puertas lógicas AND y XOR.
Acuerdo de Clave (KA): Diffie-Hellman (DH) proporciona beneficios sobre otros, ya que sólo requiere una multiplicación escalar.
Función de derivación de clave (KDF): KDF2 es ampliamente utilizado y aceptado como estándar.
Algoritmos de hash: para maximizar la seguridad y minimizar el uso de memoria y ancho de banda, usaremos SHA-256.
Función de encriptación simétrica (ENC): para maximizar la seguridad y la eficiencia, utilizamos AES-128 CTR que no requiere relleno y, por lo tanto, es más eficiente. La falta de relleno también reduce la carga de desencriptación.
Código de autentificación de mensajes (MAC): para maximizar la seguridad y minimizar el uso de memoria y ancho de banda, utilizaremos HMAC-SHA-256.
El protocolo INTfs utilizará ECIES para digerir hashes y encriptar/desencriptar datos y mensajes.
INTfs — Protocolo de Transacción
INTfs funcionará como una capa de abstracción que une INT Chain e IPFS. El propósito del protocolo no es cambiar la forma en que funciona IPFS, sino proporcionar una infraestructura que interactúe con él que proporcione mecanismos de pago para el almacenamiento y la recuperación de datos, de una manera que permita la facilidad de encriptación de datos con total privacidad y anonimato para la recepción de datos entre partes. Le permite cifrar sus datos sin necesidad de conocer el receptor previsto, pagar por la recuperación de los datos sin tener que revelar qué es lo que está solicitando, descargar el archivo sin revelar qué es lo que está descargando, de una manera que no se filtre ninguna información para los espectadores sobre los archivos descargados o quién solicitó el archivo.
La estructura básica se detalla a continuación:
Registrando las Claves de Encriptación
- Dos usuarios crean claves públicas de INT Chain, descargan el keystore y se transfieren INT.
- Luego, los usuarios crean claves de encriptación INTfs, descargan el keystore y crean una transacción de registro para publicar la parte pública de la clave en el blockchain, y vincularla así a su dirección INT.
Subir y enviar un archivo
- El usuario A desea enviar un archivo al usuario B. El usuario A introduce la dirección INT del usuario B y le pide al usuario A que seleccione el archivo. Luego pregunta cuánto tiempo desean que la red INT almacene el archivo y cualquier nota que deseen incluir en el texto encriptado.
- El monedero solicita a la red la clave pública de encriptación para el Usuario B, encripta el archivo seleccionado utilizando el protocolo ECIES especificado anteriormente con la clave pública de encriptación del Usuario B. Luego almacena el archivo encriptado localmente, nombrado por su hash suma de verificación IPFS.
- Luego, el monedero encripta el mensaje usando ECIES con la clave pública de encriptación del Usuario B, que contiene el hash y el tamaño del archivo y la nota. Luego toma el tamaño del archivo, así como el tiempo que el usuario A desea almacenar el archivo y determina la tarifa. Luego prepara la transacción de subida con la dirección del Usuario B, el criptograma (que contiene el hash del archivo), la altura de descarte, la tarifa y la firma.
- Una vez que la red valida esta transacción, el monedero inicia la subida del archivo cifrado en IPFS.
Solicitando un archivo
- El usuario B recibe una transacción que contiene un criptograma c, ECIES luego desencripta el criptograma con la clave privada del usuario B para revelar el hash, el tamaño y la nota del archivo.
- El usuario B desea luego descargar el archivo. Crean una transacción de solicitud con el hash del archivo y cuántas veces desean descargarlo.
- El monedero del usuario B genera un nonce aleatorio (n) y hashes (n || hash de archivo). Hash (n || hash de archivo) es la clave de solicitud. Luego almacena la relación entre n, hash de archivo y clave de solicitud, localmente en la biblioteca de archivos.
- El monedero del usuario B toma su clave de encriptación pública V = v • G, luego crea un secreto compartido S con la clave de encriptación pública Thearchy (que es una clave de umbral 1-de-n como se establece en [Erta07]), T = d • G . p.ej. S = v • T = v • (d • G) = d • Q
- El monedero del usuario B luego usa el secreto compartido S para encriptar el mensaje M, que contiene el nonce n, la cantidad de veces que se descargará x, y el hash de archivo solicitado usando el protocolo ECIES para ser desencriptado por los nodos de validación.
- El monedero del usuario B usa el tamaño del archivo y x para determinar la tarifa de descarga.
- El monedero del usuario B prepara la transacción de solicitud con el criptograma (que contiene n, x y hash de archivo solicitado), tarifa y firma.
- Una vez recibidos por los nodos de validación, éstos descifran c con la clave privada del nodo de validación para recuperar el hash del archivo, el nonce y para cuántas veces es válido el nonce. Esta información se almacena en una base de datos compartida que vincula nonce al hash de archivo.
- Una vez que esta transacción ha sido validada, la clave de solicitud ahora es válida para ser utilizada para la descarga.
Descargando un archivo
- Para ejecutar la descarga, el usuario selecciona el archivo de la biblioteca de archivos. El monedero luego envía la clave de solicitud a los nodos.
- Los nodos consultan al blockchain para ver si la ReqKey (clave de solicitud) ha sido “gastada”. De lo contrario, el nodo publica una transacción de “gasto” que contiene sólo la ReqKey.
- Luego, el nodo consulta la base de datos de claves hash para devolver el hash del archivo y lo envía a IPFS para iniciar la descarga.
Cálculo de la tarifa
No he podido encontrar algo que satisfaga todos los requisitos. Debería tener en cuenta el tamaño del archivo y la duración del almacenamiento para la subida del archivo, así como el tamaño del archivo y la cantidad de descargas para su recuperación. Debe ser lo suficientemente económico como para incentivar su uso, ya que es un complemento de la red, pero no demasiado económico como para ser un costo adicional sin una recompensa real para los nodos. Dado que hay un número limitado de nodos de almacenamiento en el grupo de validación, se debe determinar un tamaño de almacenamiento de red total óptimo que también exija los requisitos mínimos del nodo Thearchy. Las tarifas deberían, en lo más mínimo, compensar ese costo.
El costo de almacenamiento para VPS es de aproximadamente $ 0.10 por GB por mes. Por lo tanto, las tarifas deben ascender a al menos $ 1.30 por GB por mes ($ 0.043 por GB por día) con el grupo Thearchy actual de 13 nodos.
Debería realizarse más trabajo para definir los tiempos mínimos de almacenamiento, pero podría ser divisible por 10 segundos (por bloque de cadena principal). El máximo puede ser almacenamiento indefinido, pero la lógica de tarifa debería definirse.
INTfs — Consenso y recompensa
Prueba de Almacenamiento (PoSt)
Dado que la generación de bloques en la cadena principal es teóricamente mucho más rápida que cualquier cambio en la base de datos de almacenamiento, no tiene mucho sentido verificar el consenso en toda la red sobre el estado del almacenamiento o pagar tarifas de almacenamiento de archivos en cada bloque de la cadena principal. Lo que tiene más sentido es definir una época de verificación de estado en el orden de minutos y almacenar esa verificación de consenso como un bloque en una cadena secundaria que se puede utilizar para la autorización de pago de tarifas y la verificación independiente.
La prueba de almacenamiento propuesta es un proceso de dos pasos: el primer paso es una poda de la base de datos IPFS y el segundo paso es una muestra aleatoria de los hash de raíz de árbol de Merkle combinados para crear un hash único en un cálculo al estilo “Prueba de trabajo” que servirá como prueba de almacenamiento.
La primera parte de la máquina de estado estará dedicada a la rotación de almacenamiento. Al comienzo de cada proceso de creación de bloque, los nodos verificarán la base de datos de duración de almacenamiento de archivos y si alguno de los archivos muestra el bloque actual (o menor que) como la altura de descarte, eliminarán los enlaces para ese archivo.
La segunda parte de la máquina de estado se dedicará a probar que cada nodo almacena los archivos a lo largo del tiempo. Como se trata de un protocolo adicional para una red transaccional más grande, el algoritmo a prueba de consenso no necesita estar totalmente completo en aras de la seguridad. Los nodos deben ser probados aleatoriamente de tal manera que sea significativamente difícil falsificar un resultado válido. El riesgo asociado con no tener una verificación de almacenamiento más completa no tendría impacto en las transferencias de activos en la cadena principal, solo en la distribución de recompensas de almacenamiento. Por lo tanto, la dificultad debe ser tal que costaría más falsificar de lo que valen las recompensas.
El proceso es el siguiente, en este ejemplo, suponemos
El proceso es el siguiente, en este ejemplo, suponemos que el tiempo óptimo de bloqueo de PoSt es de 10 minutos o 60 bloques en la cadena principal:
- Una vez que se crea el bloque de activación en la cadena principal, todos los nodos verifican los archivos que deben descartarse en (discardHeight ≤ currentHeight).
- Una vez que se completa ese proceso, deriva de manera determinista un conjunto de vértices de desafío del hash del bloque de la cadena principal. Consulta el DAG de IPFS local para encontrar las raíces correspondientes para todos los puntos de desafío. Devuelve raíces.
- Comienza el puzzle PoW con las cuatro raíces y un nonce. La dificultad debe ser tal que el tiempo promedio de respuesta del nodo con una solución ~ 1 minuto.
- Si el nodo es el productor de bloques actual, envía una solución completa como propuesta a todos los nodos para validar el trabajo.
- Si el nodo no es el productor actual del bloque, envía una solución completa al nodo productor del bloque para validar el trabajo.
- Una vez que todos los nodos validan el trabajo del productor del bloque, se firma el mensaje y se envía al productor del bloque.
- El productor de bloques valida todas las propuestas, verificando el trabajo de todos los nodos de forma independiente mediante el hash del respectivo nonce con los puntos de desafío calculados. Toma en cuenta el estado válido o no válido.
- Una vez que se hayan recibido todas las firmas, se crea un bloque con la prueba del proponente, las raíces de desafío y todas las pruebas de nodo con su firma. El resultado es un bloque de pruebas con los puntos de desafío dados, vinculados al hash de bloque que los creó, que cualquiera puede verificar de forma independiente, dando una lista de todos los nodos que deberían recibir la recompensa de almacenamiento.
Este proceso seguirá la iteración de la mesa redonda DPoS existente a través de validadores.
Al no incluir las raíces derivadas de forma independiente en la propuesta a otros nodos, se garantiza (dentro de los límites de esta prueba) identificar aquellos que tienen un DAG incompleto. Cuando valida su hash dado con sus puntos, los hash no coincidirán.
Al requerir un hash puzzle de estilo PoW con dificultad no despreciable y que requiere una respuesta de solución de nodo dentro de un rango específico, hace que sea más difícil para los nodos conspirar entre sí para producir pruebas falsas.
Mecanismo de recompensa
Puede haber una mejor solución para esto, pero esto es lo mejor que se me ocurrió. Las tarifas enviadas en la transacción en la cadena principal irían a un contrato inteligente que agrega las tarifas y duraciones para definir un calendario de recompensas por bloque. Se necesita la duración, dividida por la tarifa para determinar cómo se divide esa tarifa por la recompensa en bloque durante un período determinado. Esta información se almacena en una base de datos separada.
En la creación de un bloque PoSt, la cadena principal ejecutaría una transacción coinbase para todas las direcciones que proporcionaran una prueba de estado de almacenamiento válida, con las cantidades determinadas por (recompensa de almacenamiento por bloque) dividido por (el número total de nodos a recompensar).
Al validar las transacciones de coinbase, el contrato inteligente que contiene el conjunto de tarifas de almacenamiento quemaría una cantidad igual de INT, manteniendo así una inflación neta cero.
Implicaciones
Crear la estructura transaccional como se describe nos permite romper los enlaces de información entre quienes realizan la subida, la solicitud y la descarga. Al encriptar el archivo, nadie más que el destinatario previsto puede desencriptarlo. Al enviar el archivo hash cifrado al destinatario, nadie puede ver qué archivo se está enviando. Al encriptar la solicitud con un nonce, nadie puede ver qué archivo está solicitando. Al iniciar la descarga por separado mediante una clave de solicitud, la descarga no puede vincularse a una transacción de solicitud y es independiente de una fuente de pago.
Para romper aún más las conexiones y fortalecer la privacidad, el monedero del cliente puede emitir solicitudes desde una dirección diferente a la que se enviaron los archivos e iniciar descargas desde cualquier software, a través de cualquier puerta de enlace o VPN.
Especificando el número de veces para el que el nonce es bueno, puede pagar una descarga en masa y distribuir un enlace con la ReqKey. La tarifa de almacenamiento se calcula en función del tamaño y la duración de almacenamiento decidida por el usuario desalienta los archivos grandes y las bases de datos estancadas.
No tiene sentido exigirle que tenga que poder enviar transacciones desde el dispositivo al que desea descargar. Al pagar la descarga y crear su clave de solicitud por separado de la descarga real, nos da la posibilidad de usar esas claves desde un dispositivo diferente.
Al incorporar INTfs encima de la red INT, podemos vincular la máquina de estado al mecanismo de consenso de la red y no tener que crear un mecanismo tolerante a fallas independiente con un token dedicado. Esto reduce el coste general de integración, haciendo que el servicio sea competitivo en costo y más simple de implementar.
Como este protocolo de almacenamiento y consenso está separado del consenso de la cadena principal, y los requisitos de rendimiento son mucho menores, los nodos participantes pueden incluir un segundo conjunto de nodos, tal vez un segundo registro para este trabajo. Esto ampliaría el alcance de los nodos geográficamente, aumentaría el almacenamiento y el ancho de banda para toda la red.
INTfs no requerirá que el usuario cifre los archivos almacenados en la red e incluso puede alojar directorios de datos completos.
El sistema ECIES se puede usar de manera más general para crear encriptado asimétrico para aplicaciones de datos de IoT ligeras, incluidos los MANETs.
Problemas abiertos
Cálculo de tarifas
Se debe trabajar más para determinar la lógica y los precios adecuados para lograr la participación deseada tanto de los nodos como de los usuarios. Esto es trabajo para alguien más listo que yo.
Desencriptación del umbral del nodo de validación
La desencriptación del umbral se pasó por alto en la sección Transacción de recuperación de este documento. Para encriptar el mensaje de tal manera que cualquiera del grupo de validación pueda descifrarlo, se requiere una clave de umbral de 1-de-n.
Esta clave requiere que todos los poseedores de claves compartan secretos para crear una clave pública agregada. Sin embargo, el grupo de validación no es estático, por lo que sería necesario un sistema mediante el cual la clave de umbral de grupo se recalcule y se distribuya cuando entre un nuevo validador en el grupo de validación.
Ataques
En teoría, sería posible forzar los datos a IPFS sin pagar la tarifa de almacenamiento al eludir la transacción de carga por completo o introduciendo en el software una transacción válida como comprobante de pago que no corresponde a ese archivo que se está cargando. Deben establecerse garantías para eliminar de la base de datos de almacenamiento aquellos archivos que no tienen fechas de descarte. Los usuarios no podrán recuperar estos archivos sin pago, aunque no se conocerán los hash.
Para falsificar una prueba de PoSt, todo lo que uno necesita hacer es conspirar con otro nodo para recibir las raíces de desafío a tiempo para encontrar una solución al PoW dentro del plazo permitido. Estoy seguro de que con más reflexión y siendo ingenioso con respecto a la dificultad PoW, esto se puede resolver o al menos, hacerlo significativamente menos probable.
Anonimato de IP
Para que este protocolo sea más anónimo, se podrían implementar puertas de enlace y rutas inconscientes para las descargas de archivos que separan aún más el descargador de la memoria de la red.
A medida que las transacciones pasan a través de la red, la información sobre quién o de dónde provienen las transacciones se puede filtrar por dónde se ven esas transacciones por primera vez en los nodos de la red. Esto puede conducir a determinar quién posee qué dirección, simplemente al monitorear las transacciones de esa dirección y qué nodos las recogen primero. Dandelion ++ es un protocolo que proporciona anonimato formalmente garantizado en la comunicación entre pares. La implementación de Dandelion ++ completaría este protocolo, convirtiéndolo en un protocolo de recuperación de archivos completamente libre de filtrado de información.
En confianza
El objetivo es dividir el gráfico de transacciones tanto como sea posible. Para que la red le proporcione el archivo deseado, se necesita alguna forma de comunicar qué es ese archivo y dónde desea que se envíe. Ese parece ser el mínimo común denominador en el que se puede dividir. En este marco, limitamos los vectores de ataque encriptando cada paso y rompiendo el enlace de la transacción, pero los nodos Thearchy aún conservan cierta información. Saben qué dirección publicó qué archivo, qué dirección pagó para recibirlo y cierta información limitada sobre quién lo reclamó.
Podemos minimizar esto aún más mediante la regeneración de la clave de umbral en un período definido. Esto será necesario a medida que los nuevos validadores ingresen al grupo, pero si se realiza con regularidad, las épocas anteriores de transacciones de solicitudes encriptadas ya no serán desencriptables y, por lo tanto, no podrán vincularse a una clave de solicitud específica. Todo lo que se almacenaría es una relación nonce (número aleatorio) para archivar hash.
Notas y referencias
El flujo del proceso general de ECIES se basó en el trabajo de V. Gayoso Martínez, L. Hernández Encinas y C. Sánchez Ávila y su trabajo presentado en “Una encuesta del esquema de cifrado integrado de curva elíptica” [Mart10]
[Shoup01]https://www.shoup.net/papers/iso-2_1.pdf
[Mart10] http://digital.csic.es/bitstream/10261/32671/1/V2-I2-P7-13.pdf
[Chen17]https://pdfs.semanticscholar.org/a00d/79d4d9fac939469be3a04d34d6ec5b92bcdf.pdf
[CPPbench]https://www.cryptopp.com/benchmarks.html
[Erta07]https://pdfs.semanticscholar.org/fca5/8019046317d03328eb38b61ad5dcbf83c6f6.pdf
