È possibile utilizzare curve ellittiche personalizzate nelle implementazioni TLS comuni?

12

Gli sviluppi recenti hanno lanciato alcuni dubbio sulle curve ellittiche specificate da NIST e utilizzate in molti standard come TLS (per le firme con ECDSA e accordo chiave con ECDHE).

Sembra che lo standard permetta di personalizzare , curve ECDH generate dal server che sono trasmesso durante l'handshake (solo come con DH non ellittico ).

  • Le implementazioni comuni lo supportano o sono limitate alle curve specificate dal NIST? Ho rintracciato gli handshake TLS con Google Chrome e iOS; sembra che l'estensione elliptic_curves specifichi solo le curve secp{256,384,521}r1 , e non arbitrary_explicit_{prime,char2}_curves .

  • Qual è la situazione dei certificati di curva ellittica? TLS sembra richiedere certificati X.509 conformi a RFC3279 o qualsiasi RFC che lo sostituisce (che sarebbe RFC5480). Secondo RFC3279 , è possibile; in RFC5480 , le curve esplicite o implicite sono specificamente esclusi .

In generale, in che misura le curve ellittiche personalizzate sono consentite dagli standard odierni (TLS, S / MIME ecc.) e supportate dalle varie implementazioni (OpenSSL, NSS, proprietarie)?

Se non sono supportati: perché? È più difficile trovare curve "buone" piuttosto che trovare parametri DH adatti? Le curve comuni sono più facili da verificare e / o implementare? Sono più veloci?

    
posta lxgr 09.09.2013 - 19:07
fonte

2 risposte

12

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.

    
risposta data 09.09.2013 - 19:37
fonte
0

Ci sono più famiglie di curve.

La scelta del NIST riguardava una breve equazione di weiertstrass per i campi primi  (y ^ 2 = x ^ 3 + ax + b)% p con ordine n, cofattore h.

Le curve personalizzate in SSL sono la scelta dei diversi a, b, p, n, h per la stessa equazione

I campi binari NIST sono una famiglia di curve diversa

ed25519 proviene dalla famiglia di curve edwards distorte

c25519 è una curva della famiglia di curve montgomery

Per ogni famiglia, sono necessari più di alcuni parametri in uno scambio di protocollo, inoltre è necessario il codice sorgente per implementarli. Il nuovo codice non si auto genera nella libreria TLS / SSL. Devi aspettare che la comunità opensource adotti le nuove famiglie di curve. Quindi devi anche lottare contro la riluttanza dei manutentori del prodotto a sovraffollare il loro codice sorgente. Puoi trovare sempre più famiglie di curve qui link , le più veloci potrebbero essere le curve di Huff e non sono elencate.

    
risposta data 23.08.2014 - 10:15
fonte

Leggi altre domande sui tag