El esquema de firma Boneh-Lynn-Shacham solo funciona en Curvas elípticas especiales que soportan cálculos de emparejamiento eficientes. Esto no es algo que se agrega de alguna manera sobre una firma existente; es un algoritmo de firma por derecho propio, que utiliza su propio tipo de pares de claves públicas / privadas. Si desea algo que funcione con X.509, entonces necesita una clave pública que pueda codificarse como parte de un certificado X.509. Actualmente, no hay un formato definido para una clave pública apropiada para BLS (*); X.509 es un estándar abierto, por lo que podría definir conceptualmente su propio formato y realizar su propia implementación, pero:
-
Este es un esfuerzo de considerable alcance. Requeriría de usted un conocimiento profundo de la codificación ASN.1 y DER, las curvas elípticas y los emparejamientos sobre las curvas elípticas (lo que es una zambullida en las matemáticas más bien peludas); y también fuertes habilidades para implementar algoritmos criptográficos.
-
Ya que esa sería la definición de su , no habría interoperabilidad con la implementación de nadie más, por lo que sus firmas serían verificables solo con su propio software. En ese momento, ¿por qué molestarse con X.509?
La ventaja de BLS sobre un esquema de firmas más común, como ECDSA, es que produce firmas más cortas. Más corto, no necesariamente corto. Si desea la seguridad de n -bit (tradicionalmente, n = 128; el límite tecnológico actual para el rompible está en algún lugar entre 75 y 85), una firma BLS deberá tener una longitud al menos 2n bits, mientras que ECDSA requiere 4n bits. Tenga en cuenta que incluso con BLS, todavía estamos hablando de al menos 200 bits más o menos, lo que es mucho para la entrada de potencia humana. Por ejemplo, una clave de producto de Windows usa 25 caracteres tomados en un alfabeto de 24 signos, que es suficiente para codificar hasta 114 bits, no más (porque 24 25 es aproximadamente igual a 2 114 ). Si desea que los usuarios humanos escriban valores de firma, incluso con BLS está considerando un esfuerzo similar a ingresar dos claves de producto (cuatro claves de producto con ECDSA). En la mayoría de los contextos, es probable que sea demasiado pedir (de hecho, si pudiera pedir más, entonces Microsoft también lo haría y usaría claves de producto más largas, precisamente para que pudieran usar firmas criptográficas como BLS ...).
Si aún desea profundizar en BLS, comience con la biblioteca PBC . Está escrito en C, pero la conversión de C a Java es la menor de tus preocupaciones: entender el contexto de uso y las matemáticas es mucho más difícil. No estoy al tanto de ninguna implementación Java disponible abiertamente de los emparejamientos, pero es absolutamente factible (puedo garantizarlo, porque en un momento escribí una implementación Java pura de emparejamientos). Dependiendo de su conocimiento existente en matemáticas, criptografía y desarrollo, obtener una implementación funcional y razonablemente segura podría llevarle varios años de trabajo a tiempo completo. Personalmente, ya lo he hecho ya una vez, así que conozco todas las matemáticas y criptografía, y he hecho mucha implementación de criptografía en Java, y todavía me tomaría al menos dos o tres semanas de trabajo a tiempo completo para producir algo que podría describirse como "decente".
Editar: en realidad, una simple búsqueda en Google con los términos "BLS signature java" descubre jPBC , que parece ser un puerto Java de PBC. Todos mis puntos sobre la necesidad de comprender las matemáticas y los problemas de interoperabilidad siguen pendientes.
(*) Es posible codificar una clave pública BLS usando el formato genérico para las claves públicas de curva elíptica, pero ese formato no incluye ningún campo para notificar a los decodificadores que la curva es apropiada para cualquier tipo específico de emparejamiento . Incluso si el software que recibe esa clave puede volver a calcular el grado de incrustación, no hay forma de indicar el tipo de emparejamiento a utilizar (Weil, Tate, cualquier mapa de distorsión ...).