Using secmec 8(USRSSSBPWD) on 141 vms, fails with java.security.NoSuchAlgorithmException : SHA1PRNG.

• Key: DERBY-1788
• Type: Bug
• Status: Closed
• Resolution: Won't Fix
• Priority: Minor
• Assignee: Unassigned
• Reporter: Sunitha Kambhampati
• Component/s: Network Client, Network Server
• Affects Version/s: 10.2.1.6

Description

I ran the testSecMec test with client & 141 vm and hit this error.

This could probably be a documentation issue -- that we document what level of algorithm support is required for secmec 8

T9: jdbc:derby://localhost:20000/wombat;user=neelima;password=lee;securityMechanism=8 - EXCEPTION Security exception encountered, see next exception for details.
java.sql.SQLException: Security exception encountered, see next exception for details.
at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345)
at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
at java.sql.DriverManager.getConnection(DriverManager.java:538)
at java.sql.DriverManager.getConnection(DriverManager.java:210)
at org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.getConnectionUsingDriverManager(testSecMec.java:471)
at org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.runTest(testSecMec.java:383)
at org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.main(testSecMec.java:260)
Caused by: org.apache.derby.client.am.SqlException: Security exception encountered, see next exception for details.
at org.apache.derby.client.am.EncryptionManager.<init>(EncryptionManager.java:156)
at org.apache.derby.client.net.NetConnection.initializeClientSeed(NetConnection.java:1426)
at org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(NetConnection.java:721)
at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:459)
at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:217)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:201)
at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:140)
... 5 more
Caused by: java.security.NoSuchAlgorithmException: SHA1PRNG SecureRandom not available
at java.security.Security.getAlgClassName(Security.java:576)
at java.security.Security.getAlgClassName(Security.java:598)
at java.security.Security.getImpl(Security.java:1079)
at java.security.SecureRandom.getInstance(SecureRandom.java:241)
at org.apache.derby.client.am.EncryptionManager.<init>(EncryptionManager.java:148)

Comments

[Francois Orsini]

Hi Sunitha - I'm assuming that the 141 JVM being tested was the IBM one...

Effectively, under (e.g. 1.3.x) and up to that JVM version level, the random number generator supplied by the IBMJCE provider was 'SHA1PRNG' - It then got removed as part of IBM Crypto provider 1.4.1 and 'IBMSecureRandom' was made available solely.

But it then appears that 'SHA1PRNG' made it back to the IBM Crypto provider as part of 1.4.2 and forward - which is what I tested with...

I believe this could be documented as part of the secmec comments columns in the developer's guide...

It would still be possible to fix eventhough the IBMSecureRandom's implementation uses a MD5 message digest which obviously will produce a different output that some SHA computed one, but that is fine as the generator in this context is used to generate a random number (seed) which got exchanged on both sides (client and server) - It is 8 bytes and even if the client used a different genertor than the server, it will be fine - So what could be done is to catch the SHA1PRNG NoSuchAlgorithmException exception (happening under IBM JVM 1.4.1) and then in the catch block try and new some 'IBMSecureRandom' generator which would then succeed... :-)

[Kathey Marsden]

I don't think we will fix this for 1.4.1 JVM's