32-bit 64-bit encryption calculation difference

Question

I have a simple Xades / BES implementation and two situations.

• On windows 7 32bit with java

  java version "1.7.0_25" Java(TM) SE Runtime Environment (build 1.7.0_25-b17) Java HotSpot(TM) Client VM (build 23.25-b01, mixed mode) 

• Windows Server 2008 Server has 64 bits and the same JVM.

My application works fine on 32-bit Windows 7, however, when I try to run the compiled code on Windows 2008 Server, I get an error message:

  javax.crypto.BadPaddingException: Data must start with zero at sun.security.rsa.RSAPadding.unpadV15(Unknown Source) at sun.security.rsa.RSAPadding.unpad(Unknown Source) at com.sun.crypto.provider.RSACipher.doFinal(RSACipher.java:349) at com.sun.crypto.provider.RSACipher.engineDoFinal(RSACipher.java:382) at javax.crypto.Cipher.doFinal(Cipher.java:2087) 

The problem code field is as follows:

  public static byte[] getDecryptedSignatureValue(XMLSignature signature) throws XadesElementException, InvalidKeyException { byte[] signatureValue = null; try { KeyInfo keyInfo = signature.getKeyInfo(); PublicKey key = keyInfo.getPublicKey(); Cipher cipher = getCipher("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, key); signatureValue = signature.getSignatureValue(); byte[] cipherData = cipher.doFinal(signatureValue); return cipherData; } catch (KeyResolverException | XMLSignatureException | IllegalBlockSizeException | BadPaddingException ex) { Logger.getLogger(KeyUtils.class.getName()).log(Level.SEVERE, null, ex); Logger.getLogger(KeyUtils.class.getName()).log(Level.SEVERE, null, "SignatureValue:"+ BaseUtils.toBase64String(signatureValue)); } finally { } return null; } 

The only thing I can think of is the difference in architecture. Am I missing something? What could be the problem?

Thanks in advance.

EDIT: Here are my new discoveries. 1. I tested my application on the 64-bit version of Windows 7, and there were no problems signing and checking. 2. More interestingly, I tested the application on another 64-bit Windows Server 2008 and worked successfully.

I think there is a configuration setting for something, but I could not understand that.

Answer 1

This is likely due to the selected vendor and / or vendor implementation. Note that there is a difference between filling PKCS # 1 for encryption (decoding EME-PKCS1-v1_5) and filling PKCS # 1 for signing (encoding EMSA-PKCS1-v1_5). Some providers will choose an add-on depending on the type of key (public or private), others will follow a single filling scheme depending on whether you use Cipher or Signature .

If possible, try using Signature to verify your signature, not Cipher public key decryption. Otherwise, check which providers are selected (using, for example, Cipher.getProvider() , and try to find the one that works. Note that, as you may have already discovered, this depends on the implementation, and not on the interface specification, if Decryption succeeds or fails.

He is currently trying to decode this:

 EM = 0x00 || 0x02 || PS || 0x00 || M 

with random non-zero PS and message M

However, you must make sure of this:

 EM = 0x00 || 0x01 || PS || 0x00 || T 

with PS with FF values, and T is the OID and the ASN.1 DER hash algorithm.