JDK-4953555 : Reinitialization fails from invalid key to valid key using javax.crypto.Cipher.i
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 5.0,5.0u4
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic,solaris_2.6
  • CPU: generic,sparc
  • Submitted: 2003-11-13
  • Updated: 2018-01-04
  • Resolved: 2013-07-22
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
Name: iiR10263			Date: 11/13/2003



The specification requires a Cipher object to completely lose its
state when a Cipher is reinitialized:

Note that when a Cipher object is initialized, it loses all
previously-acquired state. In other words, initializing a Cipher is
equivalent to creating a new instance of that Cipher
and initializing it.

It seems that the implementation does not completely clear previous
state. For example we may try to initialize Cipher with invalid key
and then try to initialize with valid key. The result of the attempt of
initialization with a valid key must not vary whether we had tried invalid
key before or not. But in current implementation it does vary.

Please find the code example that reproduses the situation and exception stack
trace below:

import java.io.PrintWriter;
import java.security.InvalidKeyException;
import java.security.Key;
import java.security.AlgorithmParameters;
import java.security.spec.KeySpec;
import javax.crypto.Cipher;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;

public class e5 {
 
    public static void main(String argv[]) {
        Key k;
        Cipher c;
        AlgorithmParameters params = null;
        
        String alg = "PBEWITHMD5ANDDES";
        byte[] salt = {
            (byte)0xc7, (byte)0x73, (byte)0x21, (byte)0x8c,
            (byte)0x7e, (byte)0xc8, (byte)0xee, (byte)0x99
        };
        int count = 20;
        String s = "My wonderfull password that is long enough. Tra-la-la, let me sing a song";
        Key ik = new SecretKeySpec("Ugly key".getBytes(), 
            "IsThisAlgorithmIsUglyEnough?");
        
        try {
            int kl = Cipher.getMaxAllowedKeyLength(alg) / 8;
            String p = (kl >= s.length()) ? s: s.substring(0, kl);
            KeySpec ks = new PBEKeySpec(p.toCharArray(), salt, count, kl * 8);        
        
            SecretKeyFactory skf =
                SecretKeyFactory.getInstance(alg);
     
            // PBE algorithm is symmetric.
            k = skf.generateSecret(ks);

            c = Cipher.getInstance(alg);

            try {
                System.out.println("Initialize with invalid key");
                c.init(Cipher.ENCRYPT_MODE, ik);
            } catch (InvalidKeyException ee) {
            }

            System.out.println("Initialize with good key");
            c.init(Cipher.ENCRYPT_MODE, k);

            System.out.println("passed");

        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
}

Initialize with invalid key
Initialize with good key
java.security.InvalidKeyException: No installed provider supports this key: com.sun.crypto.provider.PBEKey
        at javax.crypto.Cipher.a(DashoA6275)
        at javax.crypto.Cipher.init(DashoA6275)
        at javax.crypto.Cipher.init(DashoA6275)
        at e5.main(e5.java:48)

    
The situation is the same for all other algorithms.

Note that initialization is successfull if we comment the
initialization with invalid key (do not forget to comment the whole
"try" block, not only function call, in order to compile successfully)
- "passed" appears.

java full version "1.5.0-beta-b26"

======================================================================

Comments
The essence of this bug is a duplicate of 6733443. The class does not recheck that the provider is valid for the operation, whatever the operation is, during reinitialization.
22-07-2013

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
01-09-2004

EVALUATION This appears to have been broken by 4898428. ###@###.### 2003-11-14
14-11-2003