cryptography digital-signature dsa elliptic-curve diffie-hellman

cryptography - ¿Existe una codificación estandarizada de longitud fija para las claves públicas de la CE?



digital-signature dsa (2)

Me preguntaba si había (y espero que haya) un estándar para el tamaño de la clave pública para ECDH (curva elíptica Diffie-Hellman) y ECDSA (algoritmo de firma digital de curva elíptica) para cada tipo de curva sobre campos primos (192, 224, 256 , 384 y 521).


Estaba buscando una respuesta bastante larga y quería compartir la mía en Java. Mi tarea era obtener el tamaño de la clave de X509Certificate (el sitio web debe ser correcto)

Método # 1 - en realidad el cálculo:

ECPublicKeyImpl ecPublicKey = (ECPublicKeyImpl) certificate.getPublicKey(); int publicKeyLength = (ecPublicKey.getEncodedPublicValue().length - 1) / 2 * 8;

(Verificación si el primer byte es 0x04 podría ser agregado)

Método # 2 - extrayendo de algunos "internos":

ECParameterSpec spec = ecPublicKey.getParams(); AlgorithmParameters algorithmParameters = AlgorithmParameters.getInstance("EC"); algorithmParameters.init(spec); Provider provider = algorithmParameters.getProvider(); provider.get("KeyPairGenerator.EC KeySize");


Si utiliza una de las "curvas con nombre", el tamaño de la clave pública es fijo y depende del "tamaño de campo" de su curva subyacente.

Representación comprimida vs. sin compresión.

El tamaño de las claves públicas depende más de si se utiliza la representación "sin comprimir" o la representación "comprimida". En la forma sin comprimir, el tamaño de la clave pública es igual a dos veces el tamaño del campo (en bytes) + 1, en la forma comprimida es el tamaño del campo + 1. Entonces, si su curva está definida en secp256r1 (también llamada NIST P-256 o X9.62 prime256v1 ) , entonces el tamaño del campo es de 256 bits o 32 bytes. Y, por lo tanto, la clave pública tendría exactamente 65 bytes (32 * 2 +1) de longitud en la forma sin comprimir y 33 bytes (32 +1) de longitud en la forma comprimida.

La forma no comprimida consiste en un 0x04 (en analogía con la etiqueta DER OCTET STRING ) más la concatenación de la representación binaria de la coordenada X más la representación binaria de la coordenada y del punto público.

Caso GF (2 ^ p)

Si el campo subyacente es GF (2 ^ p), se puede pensar en x e y como elementos de [0, n-1]. Se codifican de la manera habitual en que se codifican los enteros y el espacio restante para rellenar exactamente log2 (p) / 8 bytes se rellena con ceros.

Caso GF (2 ^ m)

Para GF (2 ^ m), x e y pueden considerarse polinomios a_0x_0 + ... + a_m-1 con coeficientes a_i 0 o 1. Su representación binaria es simplemente la concatenación de los coeficientes.

Otras lecturas

Los detalles exactos se pueden encontrar en SEC1v2 . (Especialmente en la sección 2.3.3 Conversión de cadena punto-a-octeto-elíptica en las páginas 10 y 11).