Buscamos en todo el mundo on line para tenerte la respuesta para tu problema, si tienes preguntas puedes dejarnos tu duda y contestamos porque estamos para servirte.
Solución:
Si usa una de las “curvas nombradas”, entonces el público key el tamaño es fijo y depende del “tamaño de campo” de su curva subyacente.
Representación comprimida vs. sin comprimir
Público key los tamaños dependen además de si se utiliza la representación “sin comprimir” o la representación “comprimida”. En la forma no comprimida, el público key tamaño 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 se define en secp256r1 (también llamado NIST P-256 o X9.62 prime256v1), entonces el tamaño del campo es de 256 bits o 32 bytes. Y por lo tanto el público key tendría exactamente 65 bytes (32*2 +1) de longitud en forma no comprimida y 33 bytes (32 +1) de longitud en forma comprimida.
La forma sin comprimir consta de un 0x04 (en analogía con la etiqueta DER OCTET STRING) más la concatenación de la representación binaria big-endian de la coordenada x más la representación binaria de la coordenada y del punto público.
Caso GF(p)
Si el campo subyacente es GF(p) donde p es un gran número primo (en el caso de P-256, un número primo de 256 bits), entonces x e y pueden considerarse elementos de [0, p-1]. Se codifican de la manera habitual como enteros de ((log2(p)+1)/8) bytes, con los MSB rellenados con cero si es necesario.
Caso GF(2^m)
Para GF(2^m) x e y se pueden considerar como polinomios a_0 + a_1x + a_2x^2 + … + a_m-1x^m-1 con coeficientes a_i iguales a 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 la sección 2.3.3 Conversión de punto de curva elíptica a cadena de octetos en las páginas 10 y 11.)
Si aceptas, tienes la habilidad dejar un escrito acerca de qué te ha impresionado de esta división.