Pregunta

Parece ser confuso Triple-DES (> 128 bits) con DES simple (64 bits). Estoy tratando de cifrar una base de datos Derby con Triple DES (o Desede) usando Java 1.5

mensaje de foro de discusión sobre un problema con JDK 1.5 por casualidad y por lo revisado para asegurarse de que realmente estaba usando Desede y no llanura DES. Cuando creé la base de datos con una dirección URL Triple DES (168bit)

jdbc:derby:MySecureDB;dataEncryption=true;encryptionAlgorithm=DESede/CBC/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242

Yo todavía era capaz de abrirla y acceder a ella con el (normal) DES (64 bits) URL

jdbc:derby:MySecureDB;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242

Este no es el comportamiento que espero !!! No debería ser capaz de abrirlo con el algoritmo de cifrado mal. ¿Cómo puedo estar seguro de que realmente lo cifra con el algoritmo de la derecha (> 128 bits)?

Derby parece utilizar la función correcta para Java 1.5 se menciona en JCECipherProvider.java . Mi lectura del código indica que no maneja Derby Triple DES como diferente de la llanura DES ... ¿Realmente puedo confiar en que está utilizando el cifrado fuerte?

¿Fue útil?

Solución

Creo que la documentación está mal, y que en realidad no es necesario especificar el algoritmo de cifrado a utilizar cuando se utiliza un algoritmo no por defecto, ya que el algoritmo que se debe utilizar se especifica en $ DERBY_HOME / base de datos / servicio. propiedades

En mi caso, cuando he creado una base de datos con los parámetros de mis service.properties tenía el siguiente contenido (entre otras entradas que no sean pertinentes):

log_encrypt_algorithm_version=1
encryptionAlgorithm=DESede/CBC/NoPadding
dataEncryption=true
derby.encryptionBlockSize=8
encryptionKeyLength=168-24
encryptedBootPassword=472b7cc5600605333392dd10a46067d2e2935fd4c350d533-43435
data_encrypt_algorithm_version=1

Puede verificar que esto se utiliza, al cambiar el algoritmo utilizado. Si cambia el algoritmo especificado en el fichero al DES, entonces no será capaz de reiniciar la base de datos.

Por ejemplo:

$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;create=true;dataEncryption=true;encryptionAlgorithm=Blowfish/ECB/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242';
ij> quit;
$ sed -i .o 's/Blowfish/DES/' testdb/service.properties 
$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;bootPassword=$ecureC@deCanBr@kE0074242';
ERROR XJ040: Failed to start database 'testdb', see the next exception for details.
ERROR XBM06: Startup failed. An encrypted database cannot be accessed without the correct boot password.  
ij> quit;
$ sed -i .o 's/DES/Blowfish/' testdb/service.properties 
$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;bootPassword=$ecureC@deCanBr@kE0074242';
ij> quit;
$ 

Otros consejos

De acuerdo con Trabajar con cifrado partir de la Guía del desarrollador de Java DB, la primera URL se ve bien a cifrar una base de datos en la creación (porque especifica dataEncryption=true) y debería haber generado una clave de cifrado de 168 bits.

Ahora, siempre según la documentación, no creo que se debe utilizar cuando dataEncryption=true Arranque de una base de datos cifrada . Mi entendimiento es que sólo tiene que utilizar bootPassword y encryptionAlgorithm.

Admito que no he probado esto y, de hecho, realmente estoy preguntando qué sucede exactamente:

  • Si no se especifica dataEncryption y utiliza el encryptionAlgorithm mal en el segundo URL.
  • Cuando se especifica dataEncryption=true y utiliza otro encryptionAlgorithm (Qué recrear una base de datos cifrada?).

La documentación no es clara al respecto.

Creo que el parámetro encryptionAlgorithm sólo importa cuando se está haciendo en primer lugar el cifrado (es decir, cuando se crea por primera vez una base de datos cifrada, o cuando se está cifrando primero una base de datos sin cifrar).

Una vez que ha cifrado la base de datos, a partir de entonces, sólo tiene que especificar el bootPassword. Derby ya sabe qué algoritmo de cifrado utilizado.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top