Domanda

Sembra essere fonte di confusione Triple-DES (> 128 bit) con piano DES (64bit). Sto cercando di crittografare un database Derby con Triple DES (o DESede) utilizzando Java 1.5

Ho trovato questo di un problema con il JDK 1.5 per caso e in modo controllato per assicurarsi che in realtà stava usando DESede e non semplice DES. Quando ho creato il database con un URL Triple DES (168bit)

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

ero ancora in grado di aprirlo e di accesso con il (comune) DES (64 bit) URL

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

Questo non è il comportamento mi aspetto !!! Non dovrei essere in grado di aprirlo con l'algoritmo di crittografia sbagliato. Come posso fare in modo che cripta veramente con l'algoritmo a destra (> 128 bit)?

Derby sembra utilizzare la funzione giusta per Java 1.5 di cui al JCECipherProvider.java . La mia lettura del codice indica che Derby non gestisce Triple DES come diverso da pianura DES ... Posso davvero fiducia che si sta usando la crittografia forte?

È stato utile?

Soluzione

Credo che la documentazione è sbagliato, e che in realtà non è necessario specificare l'algoritmo di crittografia da utilizzare quando si utilizza un algoritmo non predefinito, in quanto l'algoritmo che dovrebbe essere utilizzato è specificato in $ DERBY_HOME / database / servizio. proprietà

Nel mio caso, quando ho creato un database con i parametri miei service.properties aveva i seguenti contenuti (tra le altre voci non rilevanti):

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

È possibile verificare che questo è usato, cambiando l'algoritmo utilizzato. Se si modifica l'algoritmo specificato nel file per DES, allora non sarà in grado di riavviare il database.

Ad esempio:

$ ../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;
$ 

Altri suggerimenti

Lavorare con crittografia dalla Guida per gli sviluppatori Java DB, il primo URL guarda bene a crittografare un database sulla creazione (in quanto specifica dataEncryption=true) e avrebbe dovuto generare una chiave di crittografia 168 bit.

Ora, sempre secondo la documentazione, non credo che si dovrebbe usare dataEncryption=true quando Avvio un database crittografato . La mia comprensione è che hai solo bisogno di usare bootPassword e encryptionAlgorithm.

Lo ammetto, non ho la prova questo e, in realtà, sono davvero chiedendo cosa succede esattamente:

  • se non si specifica dataEncryption e utilizzare il encryptionAlgorithm sbagliato nel 2 ° URL.
  • Quando si specifica dataEncryption=true e utilizzare un altro encryptionAlgorithm (vuol ricreare un database crittografato?).

La documentazione non è chiaro su questo.

Credo che il parametro encryptionAlgorithm conta solo quando si sono prima facendo la crittografia (cioè, quando si sono prima creando un database crittografato, o quando si sono prima crittografia di un database non crittografato).

Una volta che avete crittografato il database, da allora in poi, basta specificare il bootPassword. Derby sa già cosa algoritmo di crittografia utilizzato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top