db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (DERBY-2687) store/encryptDatabase.sql fails intermittently with ClassNotFoundException, Log Corrupted
Date Tue, 14 Feb 2012 22:14:01 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208067#comment-13208067
] 

Dag H. Wanvik edited comment on DERBY-2687 at 2/14/12 10:12 PM:
----------------------------------------------------------------

A possible partial theory. We validate the root password by the following algorithm:

1) retrieve the encrypted bootpassword from system.properties

2) decrypt if using the supplied bootpassword (JCECipherFactory#getDatabaseSecretKey: 
    byte[] generatedKey = decryptKey(keyString, encodedKeyCharLength, bootPassword);
    int checkKey = digest(generatedKey);

    The *digest* of the generated key is used to compare against the stored digest, cf. the
last integer after the dash in this line from
    service.properties:
 
    encryptedBootPassword=257d676070c19170-36089

    i.e. 36089 in this case. The digest method comment that says: "no matter how long the
digest is, condense it into an short".

3) compare the computed digest with the stored one, e.g. we compare one short against another
short, suggestion a chance of a false
    positive of 1/65536.

I tried to comment out the check lines:
   if (checkKey != verifyKey)
	throw StandardException.newException(errorState);

and then I see the issue if I use a wrong boot password (effectively making a false positive
every time):

    java.lang.ClassNotFoundException: ERROR XBM0U: No class was registered for identifier
41229.

So it seems we have a 1/65536 chance of getting a false positive in this check, but what I
can't see yet is where the random element comes from. Why does this fail only now and then
when we use the same bootpasswords (correct and wrong)?


    

    
                
      was (Author: dagw):
    A possible partial theory. We validate the root password by the following algorithm:

1) retrieve the encrypted bootpassword from system.properties

2) decrypt if using the supplied bootpassword (JCECipherFactory#getDatabaseSecretKey: 
    byte[] generatedKey = decryptKey(keyString, encodedKeyCharLength, bootPassword);
    int checkKey = digest(generatedKey);

    The *digest* of the generated key is used to compare against the stored digest, cf. the
last integer after the dash in this line from
    service.properties:
 
    encryptedBootPassword=257d676070c19170-36089

    i.e. 36089 in this case. The digest method comment that says: "no matter how long the
digest is, condense it into an short".

3) compare the computed digest with the stored one, e.g. we compare one short against another
short, suggestion a chance of a false
    positive of 1/65536.

I tried to comment out the check lines:
   if (checkKey != verifyKey)
	throw StandardException.newException(errorState);

and then I see the issue:

    java.lang.ClassNotFoundException: ERROR XBM0U: No class was registered for identifier
41229.

So it seems we have a 1/65536 chance of getting a false positive in this check, but what I
can't see yet is where the random element comes from. Why does this fail only now and then
when we use the same bootpasswords (correct and wrong)?


    

    
                  
> store/encryptDatabase.sql fails intermittently with ClassNotFoundException, Log Corrupted
> -----------------------------------------------------------------------------------------
>
>                 Key: DERBY-2687
>                 URL: https://issues.apache.org/jira/browse/DERBY-2687
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.1, 10.3.1.4
>         Environment: Microsoft Windows XP Professional - 5.1.2600 Service Pack 2, Sun
JVM 1.4.2_08-b03, 10.2.2.1.
> SUSE Linux Enterprise Server 10 (x86_64) (Linux 2.6.16.21-0.8-smp), Sun JVM 1.6.0_01-b06,
trunk (SVN 531991).
> Solaris 10 x86, Sun JVM 1.5.0, SVN 371617 (2006-01-23).
> Solaris 9 SPARC, Sun JVM 1.5.0, SVN 169872 (2005-05-13).
> etc...
>            Reporter: John H. Embretsen
>              Labels: derby_triage10_5_2
>         Attachments: derby.log, tmp-82.zip, wombat.zip
>
>
> Failure seen in derbyall/encryptionAll run on WinXP (10.2.2.1). So far unable to reproduce
(standalone or as part of derbyall, encryptionAll or encryptionBlowfish).
> <method>
> store/encryptDatabase.sql
> </method>
> <signature>
> Failure details:
> ********* Diff file derbyall/encryptionAll/encryptionBlowfish/encryptDatabase.diff
> *** Start: encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish 2007-05-21 05:07:55
***
> 95 del
> < ERROR XBM06: Startup failed. An encrypted database cannot be accessed without the
correct boot password.
> 95a95
> > ERROR XJ001: Java exception: 'ERROR XBM0U: No class was registered for identifier
15009.: java.lang.ClassNotFoundException'.
> Test Failed.
> *** End:   encryptDatabase jdk1.4.2_08 encryptionAll:encryptionBlowfish 2007-05-21 05:08:12
***
> </signature>
> derby.log also reports "ERROR XSLA3: Log Corrupted, has invalid data in the log stream."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message