Il NIST ha "definito" 15 "curve standard", specificato in FIPS 186- 4 . In realtà, non li hanno definiti da soli; li hanno ereditati da SEC . Queste 15 curve si aggregano in 3 gruppi:
- Le curve P- * funzionano in un "campo primo" (le coordinate del punto sono numeri interi modulo p ).
- Le curve B- * funzionano in un "campo binario" (le coordinate del punto sono valori in GF (2 m ) ).
- Le curve K- * funzionano negli stessi campi delle curve B- *, ma hanno una struttura speciale che consente calcoli più veloci.
Il NIST ha scoperto che c'era un'enorme riluttanza a implementare il supporto per queste 15 curve, per non parlare delle curve "generali", per una serie di motivi:
- La matematica coinvolta è percepita come "difficile" (è più difficile da capire di RSA o di Diffie-Hellman).
- ... ancora di più per le curve nei campi binari.
- Sebbene sia possibile scrivere codice generico per la gestione delle curve, il codice che punta a una curva specifica è spesso più semplice da implementare e più veloce. In particolare, le curve P- * lavorano con valori primi modulo il cui formato rende l'implementazione più efficiente (riduzione modulare veloce).
- Ci sono state rivendicazioni ricorrenti e di lunga data dei brevetti , rendendo "rischioso" l'uso della curva ellittica.
- ... specialmente per le curve nei campi binari;
- ... e più in generale per le curve generiche scelte per avere alcune caratteristiche utili per l'implementazione. Non è noto se una curva possa essere brevettata (al contrario di una tecnica di implementazione supportata da una struttura curva speciale), ma l'incertezza già fa una strong dissuasione.
Pertanto, le persone erano caute nell'implementare il supporto generico per le curve ellittiche, perché sembrava essere difficile, dannoso per le prestazioni e un campo minato legale. Attaccare alcune delle curve più semplici sembrava più facile, più veloce e più sicuro; e questo è quello che è successo. NIST (beh, NSA) ha formalizzato questa tendenza come la suite di crittografia " suite B ", che impone l'implementazione di esattamente due curve: P-256 e P-384.
In SSL / TLS e in X.509, possono essere usate curve arbitrarie. Tuttavia, la maggior parte delle implementazioni non supporterà curve arbitrarie. OpenSSL supporta tutte le 15 curve NIST, ma non le curve arbitrarie. Firefox supporta solo P-256 e P-384; Non sono sicuro che il codice di Microsoft (Windows, quindi Internet Explorer) accetterà più di quello (forse anche P-521). Se si tenta di utilizzare qualsiasi altra curva rispetto a P-256 o P-384, si incontreranno problemi di interoperabilità (più problemi di quelli che si ottengono tentando di utilizzare le curve ellittiche). Alcuni scrittori standard, sentendo che devono essere "pratici", hanno ammesso pienamente questo fatto e hanno semplicemente bandito l'uso di altre curve, come si vede in RFC 5480 .
Generare la propria curva non è difficile, ma sostanzialmente più difficile rispetto alla generazione dei propri parametri DH. Implica il conteggio dei punti con l'algoritmo di Schoof o una sua variante. Non sarete in grado di schiaffeggiare un generatore di curve in un'ora e un centinaio di linee di codice Java, mentre la produzione di parametri DH può essere eseguita in base a questi vincoli. Anche il costo computazionale è più alto (si otterrà comunque una bella curva in un minuto, ma non in 100 ms). Per essere brevi, le persone non lo fanno spesso, o affatto.