Comment réduire la surcharge de zkTLS tout en conservant une sécurité pratique @primus_labs adopte une approche très réfléchie au lieu d’imposer une sécurité malveillante à chaque sous-protocole, l’architecture utilise OLEe là où c’est le plus crucial > OLEe est appliquée à : - La conversion des points de Diffie-Hellman - Le calcul du tag GMAC > Le compromis de sécurité : - Le risque d’échec sélectif est strictement borné - La fuite est limitée à au plus un bit du secret de session - La haute entropie du secret pré-master TLS rend la récupération computablement impossible > Ce que cela élimine : - Les sous-preuves zero-knowledge inutiles pendant l’échange de clés - Le stockage excessif de triples authentifiés - La nécessité de charger d’énormes états de circuits brouillés en mémoire > Ce que les utilisateurs obtiennent à la place : - Un streaming progressif du calcul - Environ 150 Mo de mémoire pour des charges utiles standard de 2 Ko, selon les rapports - Une architecture d’exécution plus pratique - Moins de pression due à la surcharge réseau et de communication Un bon ingénierie cryptographique consiste à maîtriser, borner et rendre déployables les coûts C’est dans cette direction que @primus_labs avance avec zkTLS.