ECDH BouncyCastle KeyAgreement length

Question

ECDH BouncyCastle KeyAgreement length

#1 da (7 voti)

5

Sto tentando di ottenere un segreto condiviso usando i metodi ECDH di BouncyCastle in C #, tuttavia sto ricevendo una chiave condivisa che è molto più breve dei 48 byte che mi aspetto che sia.

Ho una fonte esterna attendibile che mi fornisce (Lato A) con una chiave pubblica e una chiave privata, questi sono stati generati per P192, e sono di lunghezza 48 per il pubblico e 24 per il privato.

Inoltre, sto ricevendo una chiave pubblica per il lato B per calcolare il contratto con.

Mi aspetto che la chiave condivisa abbia una lunghezza di 48, ma finisca con la lunghezza 24.

    string P192publicA = ""; // 48 length key
    string P192privateA = ""; // 24 length key
    string P192publicB = ""; // 48 length key

    DerObjectIdentifier p192Der = Org.BouncyCastle.Asn1.Sec.SecObjectIdentifiers.SecP192r1;        
    ECKeyGenerationParameters ecparams = new ECKeyGenerationParameters(p192Der, new SecureRandom());        
    ECCurve curveP192 = ecparams.DomainParameters.Curve;


    ECPrivateKeyParameters ecPrivateA = new ECPrivateKeyParameters("ECDSA", new BigInteger(P192privateA, 16), p192Der);        
    ECPublicKeyParameters ecPublicA = new ECPublicKeyParameters("ECDSA", curveP192.DecodePoint(Hex.Decode("04" + P192publicA)), p192Der);
    ECPublicKeyParameters ecPublicB = new ECPublicKeyParameters("ECDSA", curveP192.DecodePoint(Hex.Decode("04" + P192publicB)), p192Der);


    IBasicAgreement aKeyAgreeBasic = AgreementUtilities.GetBasicAgreement("ECDHC");
    aKeyAgreeBasic.Init(ecPrivateA);

    BigInteger k = aKeyAgreeBasic.CalculateAgreement(ecPublicB);

Il mio risultato in esadecimale è solo di lunghezza 24 mentre mi aspettavo 48.

C'è qualcosa di sbagliato nella mia comprensione del meccanismo dell'accordo chiave? Non ero sicuro della decodifica di un punto, ho visto negli esempi saltellanti aggiungere "04" prima di decodificare un punto e ogni altro prefisso che ho provato ha generato un'eccezione.

Qualche consiglio sarà molto apprezzato!

.net diffie-hellman ecc

posta g3trans 10.07.2015 - 23:11

fonte

1 risposta

Leggi altre domande sui tag .net diffie-hellman ecc

PCI DSS - rete VPN? DHE_RSA Lunghezza pubkey in TLS 1.2?

score 7 · Accepted Answer

Una curva ellittica è un punto in uno spazio bidimensionale, quindi ha due coordinate (di solito chiamate X e Y ) che sono valori in alcuni campi. Nel caso di P-192, il campo consiste in interi modulo un primo p di lunghezza 192 bit ( p si trova tra 2 ¹⁹¹ e 2 ¹⁹²). I punti della curva sono le coppie ( X , Y ) che soddisfano l'equazione della curva ( Y ² = X ³ + aX + b per due costanti a e b che definisce la curva). Succede che il numero di punti sulla curva (la curva "ordine") è un intero n il cui valore è anche vicino a (ma leggermente inferiore a) 2 ¹⁹² . La curva specifica (le costanti a e b ) sono state scelte in modo che n sia primo.

Un tasto DH privato è un modulo intero n . Pertanto, può sempre essere codificato come 192 bit (24 byte) poiché n stesso è un numero intero a 192 bit.

Un tasto DH pubblico è un punto; è ciò che le due parti si scambiano l'una con l'altra. Per la chiave privata u , la chiave pubblica corrispondente è il punto uG (moltiplicazione di un punto di curva convenzionale G , che fa parte della definizione della curva ).

Quando due parti U e V fanno un ECDH, usano (o generano casualmente) le loro chiavi private u e v e invia l'una all'altra la corrispondente chiave pubblica uG e vG . Il segreto condiviso risultante è quindi il punto uvG che entrambi possono calcolare (ma che gli intercettatori non possono calcolare, che è il punto di ECDH).

Accade che ECDH sia definito dallo standard ANSI X9.63 e quello standard dice che l'effettivo segreto condiviso non è il punto completo uvG , ma solo la X coordinata del punto uvG . Quella coordinata è un elemento del campo in cui stiamo lavorando, cioè un modulo intero p . Pertanto, può essere codificato su 192 bit, motivo per cui si ottengono solo 24 byte. Si noti che il valore è un modulo intero p (il modulo di campo), mentre le chiavi private sono modulo n (l'ordine delle curve); p e n sono distinti (ma entrambi sono valori di 192 bit nella curva P-192).

Potresti chiedere come viene definita l'ECDH in questo modo. Il motivo è principalmente che le coordinate del punto sono ridondanti: poiché un punto ( X , Y ) deve soddisfare l'equazione della curva, da X da solo è possibile calcola X ³ + aX + b = Y ², quindi ottieni il quadrato della coordinata Y . In un campo, un dato valore può avere al massimo due radici quadrate, quindi se hai la coordinata X allora puoi recuperare Y e - Y , vale a dire quasi il punto. In questo senso, con la sola coordinata X , hai quasi tutta la segretezza che puoi aspettarti da ECDH.

(Ciò implica che ECDH è ancora possibile quando le due parti si inviano reciprocamente solo le coordinate X delle rispettive chiavi pubbliche uG e vG , a condizione che entrambi ricalcolino il Y mancante. Tuttavia, non tutte le implementazioni supportano questo dato che implica un codice aggiuntivo per le radici quadrate, e vi è una certa incertezza sui possibili brevetti sull'argomento. tutto generalità, questo è chiamato compressione dei punti .)