¿Cuál es el formato de una clave X9.62?

Question

¿Cuál es el formato de una clave X9.62?

#1 de dave_thompson_085 (2 votos)

4

RFC8292 contiene esta gema:

The "k" parameter includes an ECDSA public key [FIPS186] in
uncompressed form [X9.62] that is encoded using base64url encoding
[RFC7515].

Hay un ejemplo del uso de esta clave un poco más abajo:

Authorization: vapid
   t=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiJodHRwczovL3
     B1c2guZXhhbXBsZS5uZXQiLCJleHAiOjE0NTM1MjM3NjgsInN1YiI6Im1ha
     Wx0bzpwdXNoQGV4YW1wbGUuY29tIn0.i3CYb7t4xfxCDquptFOepC9GAu_H
     LGkMlMuCGSK2rpiUfnK9ojFwDXb1JrErtmysazNjjvW2L9OkSSHzvoD1oA,
   k=BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dR
     uU_RCPCfA5aq9ojSwk5Y2EmClBPs

La clave es el campo k= en el ejemplo.

Esto no parece estar en formato ASN.1:

$ cat vapidkey
-----BEGIN PUBLIC KEY-----
BA1Hxzyi1RUM1b5wjxsn7nGxAszw2u61m164i3MrAIxHF6YK5h4SDYic-dRuU_RCPCfA5aq9ojSwk5Y2EmClBPs
-----END PUBLIC KEY-----
$ openssl asn1parse -in vapidkey -i
    0:d=0  hl=2 l=  13 prim: OCTET STRING      [HEX DUMP]:47C73CA2D5150CD5BE708F1B27
Error in encoding
139686682194112:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:91:

¿Cómo puedo analizar este formato?

Desafortunadamente, el estándar X9.62 parece estar detrás de un muro de pago. Está bien, no necesito el estándar completo , solo necesito leer una clave y pasar los fragmentos relevantes a una biblioteca que sepa cómo manejarlo. Pero eso parece más difícil de lo que parece; Este formato no es comprendido inmediatamente por las bibliotecas que he probado, por lo que tendré que hacer algunas conversiones yo mismo. Sin embargo, es bastante difícil si no sé en qué formato están las claves.

ecc nist file-types

pregunta Wouter Verhelst 09.05.2018 - 18:03

fuente

1 respuesta

Lea otras preguntas en las etiquetas ecc nist file-types

Inspeccionar elementos de código en el navegador al iniciar sesión ¿Qué tan segura es la identidad central de Microsoft ASP.NET?

score 2 · Accepted Answer

De hecho, no es ASN.1.

(AFAIK todo) Los formatos de X9.62 se replican en SEC1 libre de SECG con un punto de curva (que es el real valor de clave pública, excluyendo metadatos) en 2.3.3 y 2.3.4.

El formato de punto sin comprimir, que tiene, es solo un octeto 04 seguido de las coordenadas X e Y como un entero bigendiano sin signo determinado por el campo que subyace a la curva, que debe saber ya, generalmente la clave pública está incorporada en un SPKI X.509 (ver más abajo) que identifica la curva y, por lo tanto, proporciona su tamaño de campo. El formato comprimido, que también es común, es un octeto 02 o 03 que designa si Y es par o impar (para una curva de característica principal, a menudo abreviado prime y notado Fp) seguido de X solamente.

Nunca he visto ninguna biblioteca que implemente ECC en absoluto que no implemente el formato de punto sin comprimir (X9.62), y casi ninguna que no implemente comprimido también. Es mucho más común tener un desacuerdo sobre el formato para una firma de ECDSA, pero ese no es su caso.

También tenga en cuenta que el esquema base64url sin relleno utilizado en 8292 y 7515 no es compatible con el (tradicional) base PEM / SMIME 64 utilizado por OpenSSL. Los dos caracteres 'extra' son diferentes, y OpenSSL requiere relleno (si no es un múltiplo exacto de 3), y en la mayoría de los casos requiere saltos de línea. Más aún, se supone que el tipo PEM 'PUBLIC KEY' es una estructura X.509 SubjectPublicKeyInfo, denominada PUBKEY en la API (y código) de OpenSSL, que incluye la secuencia y secuenciador AlgorithmIdentifier y BIT STRING, aunque eso no importa aquí porque no No intente leerlo como una clave solo como ASN.1 arbitrario.