Bouncy Castle: documento firmado por el remitente y que solo se puede leer por el receptor

Question

Bouncy Castle: documento firmado por el remitente y que solo se puede leer por el receptor

#1 de Bruno (2 votos)
#2 de Georgios (1 votos)
#3 de kbs (1 votos)
#4 de D.W. (0 votos)

2

Estoy creando una aplicación que requiere una transferencia de datos segura. En particular, el remitente tiene un archivo de datos que debe enviarse al destinatario. Se requiere que solo el receptor pueda leer los datos. También se requiere que el receptor pueda saber con seguridad que los datos provienen del remitente.

El remitente y el destinatario tienen una relación comercial a largo plazo y habrán intercambiado claves públicas. Los archivos de datos a transmitir no son pequeños.

Supongo que Bouncy Castle es una buena ruta, pero estoy abierto a otras sugerencias.

He leído toda la documentación de BC que puedo encontrar (ninguna) y mire la API y algunos ejemplos que encontré en Internet. Parece que quiero usar CMSEnvelopedDataGenerator , pero tengo algunas preguntas específicas:

Exactamente, ¿cómo configuro el cifrado de datos (probablemente utilizando AES)?
Exactamente, ¿cómo configuro la doble firma (usando la clave privada del remitente y la clave pública del destinatario)?
¿Puedo configurarlo para que los datos estén comprimidos / comprimidos antes de ser cifrados?
¿Es segura y segura de usar la implementación de BC de este escenario? ¿Hay configuraciones / algoritmos / parámetros específicos que se requieren para garantizar su seguridad?
¿Existe una aplicación independiente de terceros disponible que puedo usar para leer / validar que la salida de BC es correcta y segura?
¿Qué más debería preguntar (soy un novato de criptografía)? ¿O hay una mejor manera de hacer lo que estoy buscando?

Pregunta de seguimiento Al hacer más investigaciones, encontré este article . Mis requisitos son tales que no debo ser susceptible de reenvío subrepticio. El artículo es antiguo. ¿Las diversas tecnologías "seguras" siguen sufriendo las fallas mencionadas? ¿Alguno de los productos / bibliotecas estándar proporciona una solución segura de manera estándar?

cryptography encryption java

pregunta Rob 05.06.2012 - 06:28

fuente

4 respuestas

Lea otras preguntas en las etiquetas cryptography encryption java

Brute-force una frase de contraseña, generada por 'pwgen 16 -s', de un archivo GPG CAST5 ¿Deben los administradores cambiar sus contraseñas regularmente?

score 2 · Answer 1

The BouncyCastle OpenPGP o Los paquetes S / MIME deben permitirle hacer lo que quiera. OpenPGP será más apropiado cuando se utilicen certificados de OpenPGP (a menudo denominados "claves públicas PGP"), mientras que S / MIME será más apropiado cuando se usen certificados X.509.

No hay "doble firma" involucrada: usted firmará con la clave privada del remitente y cifrará con la clave pública del destinatario.

GnuPG (u otras implementaciones de OpenPGP) debería permitirle probar los resultados si utiliza la implementación OpenPGP de BouncyCastle.

Tenga en cuenta que debe firmar primero y cifrar después, no al revés, sobre la base de que el firmante debe poder ver lo que firma, y el destinatario para poder descifrar y leer, pero mantener la firma adjunto si es necesario.

No parece haber muchos ejemplos de OpenPGP de BouncyCastle, pero esta entrada de blog parece bastante completa (aunque aún así debería firmar primero y luego cifrarla). La compresión también se tiene en cuenta.

score 1 · Answer 2

No tengo experiencia con la API de Bouncy Castle, pero intentaré aclarar las cosas criptográficamente y puede ayudarte a encontrar el camino (ya que mencionas que eres un novato de criptografía):

P1: Es un proceso de dos pasos:

Primero, debe cifrar su mensaje utilizando un algoritmo de clave simétrica como AES.
Luego, cifra la clave del paso anterior usando un algoritmo no simétrico (por ejemplo, RSA) y la clave pública del destinatario.
Usted envía sus mensajes (cifrados simétricamente) a su destinatario a lo largo de su clave (cifrados no simétricamente). Utiliza el mismo algoritmo (no simétrico) y su clave privada para descifrar la clave que le dará acceso al mensaje (cifrado simétricamente).

P2: Sólo el remitente firma su mensaje con su propia clave privada. En pocas palabras, el proceso es: (1) Hacer un hash del mensaje (2) cifrarlo usando la clave privada del remitente (3) enviar el mensaje + el hash cifrado (4) el receptor hace un hash del mensaje recibido (5 ) también descifra el hash cifrado recibido utilizando la clave pública del remitente (6) si los dos coinciden, entonces el mensaje realmente proviene del remitente y no se ha atenuado en el camino.

P3: Esto no tiene nada que ver con la API criptográfica; encuentre una biblioteca que comprima sus mensajes y utilícela antes de aplicar la criptografía.

P5: esperaría que si BC implementa correctamente los estándares de criptografía sería interoperable con OpenSSL o GPG, etc.

P6: ¿Ha considerado usar una solución preparada como GPG o OpenSSL (por ejemplo, dentro de scripts)? También podría usar la funcionalidad de firma / encriptación de sus clientes de correo electrónico (usando S / MIME) y certificados autofirmados (por ejemplo, MS Outlook tiene Funcionalidad de cifrado / firma digital incorporada, la mayoría de los otros clientes de correo electrónico también lo hacen.)

score 1 · Answer 3

Para responder a tus preguntas 1-3:

Estoy usando la API BouncyCastle 1.47 (es decir, con las interfaces del operador livianas) con openPGP para la implementación de la clave pública / privada. De hecho, es bastante una tarea averiguar qué está pasando; Pero lo intenté hace poco. Caveat emptor, como todo lo que puedo decir es que "funciona para mí (TM)".

Consulte Ver código para lograr esto.

También uso el encabezado "destinatario anónimo", que evita que alguien que puede ver los datos identifique la identificación de la clave pública del destinatario (incluso si no pueden descifrarla). Esto puede o no ser relevante para usted, pero con este mecanismo, también debe utilizar el correspondiente descifrado / a> que prueba todas las claves disponibles.

No puedo hablar por las preguntas 4 y amp; 5, pero algunos pensamientos específicos de openPGP para la pregunta 6:

1) Depurar el contenido generado con GnuPGP es una buena manera de identificar problemas.

gpg --list-packets también es muy útil.

2) Cree un conjunto de claves con claves de firma y cifrado separadas (de modo que en realidad utilizará 2 conjuntos de pares de claves públicas / privadas). Algunos teorías sobre por qué esto es necesario .

2) Use claves de longitud apropiada y explícita siempre que sea posible, ya que el proveedor predeterminado basado en Java crea claves bastante cortas. (Consulte generación de códigos clave para las opciones) .)

3) Es posible que desee considerar "preconstruir" un mensaje de revocación firmado en el momento de la generación de la clave, en caso de que una de las partes olvide su contraseña o pierda su clave privada. Esto se puede liberar para invalidar las claves públicas previamente intercambiadas.

score 0 · Answer 4

Le recomiendo que utilice GPG (GnuPG) o PGP o OpenPGP para cifrar y firmar sus mensajes. Su formato de mensaje y código criptográfico está bien revisado. Usar un formato y código criptográfico existente es más confiable si lo hace usted mismo con BouncyCastle, ya que lo salvará de los detalles que de lo contrario podría joder. Eso debería hacer que resolver su problema sea bastante fácil.