ECDH BouncyCastle KeyAgreement length

Question

ECDH BouncyCastle KeyAgreement length

#1 de Thomas Pornin (7 votos)

5

Estoy intentando obtener un secreto compartido utilizando los métodos ECDH de BouncyCastle en C #, sin embargo, estoy recibiendo una clave compartida que es mucho más corta que los 48 bytes que espero que sean.

Tengo una fuente externa de confianza que me proporciona (Lado A) una clave pública y una clave privada, que se generaron para P192, y tienen una longitud de 48 para el público y 24 para el privado.

Además, estoy recibiendo una clave pública para que el lado B calcule el acuerdo con.

Espero que la clave compartida tenga una longitud de 48, pero que termine con la longitud 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);

Mi resultado en hexadecimal solo tiene una longitud de 24, mientras que yo esperaba 48.

¿Hay algún error con mi comprensión del mecanismo de acuerdo clave? No estaba seguro de la decodificación de un punto, vi en los ejemplos inflables que agregaron "04" antes de decodificar un punto, y todos los demás prefijos que intenté arrojaron una excepción.

¡Cualquier consejo será muy apreciado!

diffie-hellman ecc .net

pregunta g3trans 10.07.2015 - 23:11

fuente

1 respuesta

Lea otras preguntas en las etiquetas diffie-hellman ecc .net

PCI DSS - ¿red VPN? ¿Podemos determinar con qué seguridad se almacenan los archivos en un servicio de almacenamiento en la nube?

score 7 · Accepted Answer

Una curva elíptica es un punto en un espacio bidimensional, por lo tanto, tiene dos coordenadas (generalmente llamadas X y Y ) que son valores en algún campo. En el caso de P-192, el campo consiste en números enteros un primo p de 192 bits de longitud ( p se encuentra entre 2 ¹⁹¹ y 2 ¹⁹²). Los puntos de la curva son los pares ( X , Y ) que cumplen la ecuación de la curva ( Y ² = X ³ + aX + b para dos constantes a y b que definen la curva). Sucede que el número de puntos en la curva (la "orden" de la curva) es un número entero n cuyo valor también es cercano (pero algo menor que) 2 ¹⁹² . La curva específica (las constantes a y b ) se eligieron para que n sea primordial.

Una clave DH privada es un módulo entero n . Por lo tanto, siempre se puede codificar como 192 bits (24 bytes), ya que n es un entero de 192 bits.

Una clave pública DH es un punto; Es lo que las dos partes se envían. Para la clave privada u , la clave pública correspondiente es el punto uG (multiplicación de un punto de curva convencional G , que forma parte de la definición de la curva ).

Cuando dos partes U y V hacen un ECDH, usan (o generan aleatoriamente) sus claves privadas u y v , y enviarse entre sí las claves públicas correspondientes uG y vG . El secreto compartido resultante es el punto uvG que ambos pueden computar (pero que los intrusos no pueden computar, que es el punto de ECDH).

Sucede que ECDH está definido por el estándar ANSI X9.63 y ese estándar dice que el secreto compartido real no es el punto completo uvG , sino que solo la coordenada X del punto uvG . Esa coordenada es un elemento del campo en el que estamos trabajando, es decir, un módulo entero p . Por lo tanto, puede codificarse sobre 192 bits, por lo que solo obtiene 24 bytes. Tenga en cuenta que el valor es un módulo entero p (el módulo de campo), mientras que las claves privadas son el módulo n (el orden de la curva); p y n son distintos (pero ambos son valores de 192 bits en la curva P-192).

Puede preguntar cómo es que ECDH se define de esa manera. La razón es principalmente que las coordenadas del punto son redundantes: ya que un punto ( X , Y ) debe cumplir la ecuación de la curva, solo desde X compute X ³ + aX + b = Y ², así obtienes el cuadrado de la coordenada Y . En un campo, un valor dado puede tener como máximo dos raíces cuadradas, por lo que si tiene la coordenada X , puede recuperar Y y - Y , es decir, casi el punto completo. En ese sentido, solo con la coordenada X , casi tiene todo el secreto que puede esperar de ECDH.

(Esto implica que ECDH todavía es posible cuando las dos partes se envían entre sí solo las coordenadas X de sus respectivas claves públicas uG y vG , siempre y cuando ambos vuelvan a calcular el Y faltante. No todas las implementaciones son compatibles con eso, ya que involucra un código adicional para las raíces cuadradas, y existe cierta incertidumbre acerca de posibles patentes sobre el tema. generalidad, esto se llama compresión de puntos .)