Il calcolo multipartitico firma con due algoritmi di chiave: ECDSA su secp256k1 ed EdDSA su Ed25519 (disponibile a breve). Questa pagina illustra il protocollo ECDSA a soglia, DKLS23, e le modifiche apportate da Google. Per gli algoritmi supportati, consulta Blockchain supportate.
ECDSA a soglia e DKLS23
A differenza di altri schemi di firma, il problema della firma a soglia per ECDSA è notoriamente difficile. Fino al 2017, la maggior parte delle soluzioni comportava dei compromessi significativi.
Nel 2018, DKLS ha presentato la prima soluzione per la firma 2-out-of-2 per ECDSA che si basava solo su ipotesi crittografiche basate su ECDSA (ad esempio, non richiedeva Paillier, RSA o altre famiglie diverse di ipotesi di durezza crittografica). L'idea innovativa di questo protocollo è stata un nuovo modo di sostenere la sicurezza contro i comportamenti illeciti per un approccio basato su MPC (i tentativi precedenti di applicare tecniche MPC generiche sicure contro i comportamenti illeciti hanno portato a protocolli che richiedevano minuti per l'esecuzione anziché millisecondi).
I successivi miglioramenti apportati dagli stessi autori hanno portato a un protocollo k-out-of-n e, infine, il miglioramento DKLS23 ha portato a un framework generico per l'ECDSA a soglia k-out-of-n a 3 round che ha catturato tutti gli approcci precedenti e ha identificato l'approccio DKLS come il più efficiente in base a metriche sul rendimento degne di nota. In particolare, questa versione del protocollo si basa solo su primitive di impegno ideale e di moltiplicazione tra due parti. Il protocollo risultante richiede millisecondi di calcolo a singola cifra per parte (con un'accelerazione di un ordine di grandezza rispetto agli approcci concorrenti) e, soprattutto, si basa su primitive crittografiche più semplici che utilizzano solo operazioni su curve ellittiche (a differenza delle costose operazioni omomorfiche di Paillier e delle costose prove di intervallo zero-knowledge e di buona formazione delle chiavi di crittografia richieste in altri lavori).
Il protocollo è stato valutato internamente da diversi revisori, tra cui esperti assunti da Coinbase e altri esperti di crittografia. Doerner e Roy DR26 hanno recentemente identificato un errore di calcolo nell'analisi della sicurezza per il moltiplicatore DKLS che richiede altre 22 chiamate di OT per ottenere i 120 bit di sicurezza dichiarati. Questa modifica è stata implementata. Analogamente, altri revisori esterni hanno segnalato dettagli mancanti nella descrizione del protocollo per quanto riguarda le implicazioni della trasmissione nel modello di canale point-to-point (in particolare, è importante ripetere alcuni parametri di configurazione per ottenere una conoscenza comune).
Il lavoro successivo di Google sul protocollo ha rafforzato notevolmente l'implementazione, ridotto le risorse necessarie per gestire il protocollo su larga scala ed esteso la funzionalità dello schema. Ad esempio, la letteratura accademica non specifica la selezione e l'implementazione dell'oracolo casuale. Sebbene sia un'astrazione accademica utile, l'implementazione di Random Oracle è un'attività complessa che ha portato a diversi difetti documentati dai controlli di sicurezza.
Un aspetto degno di nota del nostro lavoro è stato lo sviluppo di un sistema di tipi (basato su due operazioni di spawn e fork, nonché sull'uso rigoroso di sistemi di tipi per impedire la copia, lo spostamento e l'aliasing dei puntatori agli oracoli) per garantire che ogni sessione e sottosessione utilizzi un oracolo casuale diverso.
Un altro importante miglioramento riguarda la selezione degli identificatori di sessione e sottosessione. Il modello UC, e quindi tutti i protocolli che si sono dimostrati sicuri in questo modello, richiedono che l'ambiente fornisca nuovi identificatori di sessione. In pratica, un sistema deve garantire che l'avversario non possa violare questa ipotesi e, per farlo, di solito richiede ai partecipanti di mantenere uno stato illimitato. Abbiamo migliorato il protocollo DKLS originale con round aggiuntivi per selezionare questo identificatore in modo da richiedere solo uno stato di dimensioni costanti.
Nel complesso, il protocollo aggiornato e rafforzato completa comunque un'operazione di firma in decine di millisecondi.
In termini di funzionalità, l'articolo DKLS23 prende in considerazione solo la struttura di accesso con soglia k-out-of-n standard. In pratica, i clienti potrebbero richiedere una struttura di accesso che imiti le regole dell'organizzazione. La letteratura crittografica contiene molti approcci alla progettazione di strutture di accesso per la condivisione di secret. In questo caso, abbiamo esteso il protocollo DKLS per supportare strutture di accesso più generali che possono essere composte da gate di soglia k-out-of-n. Ciò consente di applicare policy come "2 su 3 dei seguenti gruppi: (a) il cliente, (b) 2 su 10 dei responsabili del controllo dei rischi, (c) 2 su 3 dei responsabili dei reparti finanziario, legale e contabile" e così via.
Nell'API v1beta, questa struttura di accesso viene definita come policy della chiave di un KeyRing, nel campo keyPolicy. Ogni chiave creata nel keyring utilizza questa versione. Una policy della chiave può avere al massimo due livelli: la regola di soglia principale e le regole di soglia direttamente sotto di essa. Una regola di soglia sotto la radice non può contenere un'altra regola di soglia.