Lo schema di firma di Boneh-Lynn-Shacham funziona solo in speciali curve ellittiche che supportano calcoli di abbinamento efficienti. Questo non è qualcosa che in qualche modo aggiungi sopra una firma esistente; è un algoritmo di firma a sé stante, che utilizza il proprio tipo di coppie di chiavi pubbliche / private. Se vuoi qualcosa che funzioni con X.509, allora hai bisogno di una chiave pubblica che possa essere codificata come parte di un certificato X.509. Attualmente, non esiste un formato definito per una chiave pubblica appropriata per BLS (*); X.509 è uno standard aperto in modo che tu possa definire concettualmente il tuo formato e realizzare la tua implementazione, ma:
-
Questo è uno sforzo di notevole portata. Richiederebbe una conoscenza approfondita di ASN.1 e codifica DER, curve ellittiche e accoppiamenti su curve ellittiche (che è un tuffo nella matematica piuttosto pelosa); e anche abilità forti nell'implementazione di algoritmi crittografici.
-
Poiché sarebbe la tua definizione, non ci sarebbe alcuna interoperabilità con l'implementazione di nessun altro, quindi le tue firme sarebbero verificabili solo con il tuo software. A quel punto, perché preoccuparsi di X.509?
Il vantaggio di BLS su uno schema di firma più comune, come ECDSA, è che produce firme più brevi. Più breve, non necessariamente breve. Se si desidera n -bit sicurezza (tradizionalmente, n = 128, il limite tecnologico corrente per il breakable è compreso tra 75 e 85), una firma BLS dovrà avere lunghezza almeno 2n bit, mentre ECDSA richiede bit 4n . Si noti che anche con BLS, stiamo ancora parlando di almeno 200 bit o giù di lì, che è molto per l'input alimentato dall'uomo. Ad esempio, un codice Product Key di Windows utilizza 25 caratteri in un alfabeto a 24 segni, che è sufficiente per codificare fino a 114 bit, non più (perché 24 25 è approssimativamente uguale a 2 114 ). Se si desidera che gli utenti umani digitino i valori delle firme, anche con BLS si sta valutando uno sforzo simile all'immissione di due codici prodotto (quattro codici prodotto con ECDSA). Nella maggior parte dei casi questo è probabilmente troppo chiedere (in effetti, se potessi chiedere di più, allora anche Microsoft lo farebbe e userà chiavi di prodotto più lunghe, proprio così che potrebbero utilizzare firme crittografiche come BLS ...).
Se vuoi ancora approfondire BLS, inizia con la libreria PBC . È scritto in C, ma la conversione da C a Java è l'ultima delle tue preoccupazioni: capire il contesto di utilizzo e la matematica è molto più difficile. Non sono a conoscenza di alcuna implementazione Java degli abbinamenti disponibile, ma è assolutamente fattibile (posso garantirlo, perché a un certo punto ho scritto una pura implementazione Java di accoppiamenti). A seconda delle tue conoscenze attuali in matematica, crittografia e sviluppo, ottenere un'implementazione funzionale e ragionevolmente sicura potrebbe richiedere diversi anni di lavoro a tempo pieno. Personalmente, ho già fatto una volta, quindi conosco tutti i calcoli e la crittografia, e ho fatto molta implementazione crittografica in Java, e mi ci vorrebbero almeno due o tre settimane di lavoro a tempo pieno per produrre qualcosa che possa essere definito "decente".
Modifica: in realtà una semplice ricerca su Google con i termini "firma BLS java" scopre jPBC , che sembra essere una porta Java di PBC. Tutti i miei punti sulla necessità di comprendere la matematica e i problemi di interoperabilità sono ancora validi.
(*) È possibile codificare una chiave pubblica BLS utilizzando il formato generico per le chiavi pubbliche della curva ellittica, ma tale formato non include alcun campo per comunicare ai decodificatori che la curva è appropriata per qualsiasi tipo specifico di accoppiamento . Anche se il software che riceve quella chiave può ricalcolare il grado di incorporamento, non c'è modo di indicare il tipo di accoppiamento da usare (Weil, Tate, qualsiasi mappa di distorsione ...).