
Anonymous
Not applicable
2011-02-08
10:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[resolved] Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction
Hi,
I developed some piece of code which implements AES-256 symetric cipher in CBC mode. I needed to replace the policy files of Java runtime. You need this to use keys bigger than 128 bits. So I did this, I configured both eclipse and talend runtime environment in the same way. But when I copy my fully functional code from Eclipse Java project into Talend Routine and try to run crypto methods with key bigger more than 128 bits, it throws an exception on Illegal key size, which means that it is using the standard policy files. But the IDE is configured to use JAVA_HOME with already updated policy files.
I will be glad for any suggestion. Of course the workaround is to use 128-bit length key instead of the 256-bit one, but it doesn't make any sence to me. Why 2 environments configured in the same way work in one case and doesn't work in the second one.
Seems like Talend has it's own library and maybe replace these library files in run-time. Could it be that case? Could Talend act like this?
Thank you very much.
This is the piece of code which test environment for Unlimited Stregth Jurisdiction>
Best regards,
Ladislav Jech
I developed some piece of code which implements AES-256 symetric cipher in CBC mode. I needed to replace the policy files of Java runtime. You need this to use keys bigger than 128 bits. So I did this, I configured both eclipse and talend runtime environment in the same way. But when I copy my fully functional code from Eclipse Java project into Talend Routine and try to run crypto methods with key bigger more than 128 bits, it throws an exception on Illegal key size, which means that it is using the standard policy files. But the IDE is configured to use JAVA_HOME with already updated policy files.
I will be glad for any suggestion. Of course the workaround is to use 128-bit length key instead of the 256-bit one, but it doesn't make any sence to me. Why 2 environments configured in the same way work in one case and doesn't work in the second one.
Seems like Talend has it's own library and maybe replace these library files in run-time. Could it be that case? Could Talend act like this?
Thank you very much.
This is the piece of code which test environment for Unlimited Stregth Jurisdiction>
public static void testEnvironment()
throws
NoSuchAlgorithmException,
NoSuchPaddingException,
GeneralSecurityException
{
// 64bits testing data block
byte[] data = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 };
// 128bit key
SecretKey key128 = new SecretKeySpec(new byte[] { 0x00, 0x01, 0x02,
0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c,
0x0d, 0x0e, 0x0f }, ALGORITHM);
// sipher initialization and try to crypt data block with specified key
Cipher cipher = Cipher.getInstance(ALGORITHM + "/" + BLOCK_MODE + "/" + PADDING);
cipher.init(Cipher.ENCRYPT_MODE, key128, CBC_SALT);
cipher.doFinal(data);
System.out.println("128-bit test: O.K.");
// 192bit key
// sipher initialization and try to crypt data block with specified key
SecretKey key192 = new SecretKeySpec(new byte[] { 0x00, 0x01, 0x02,
0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c,
0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16,
0x17 }, ALGORITHM);
// sipher initialization and try to crypt data block with specified key
cipher.init(Cipher.ENCRYPT_MODE, key192, CBC_SALT);
cipher.doFinal(data);
System.out.println("192-bit test: O.K.");
// 256key
SecretKey key256 = new SecretKeySpec(new byte[] { 0x00, 0x01, 0x02,
0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c,
0x0d, 0x0e, 0x0f, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16,
0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f },
ALGORITHM);
// sipher initialization and try to crypt data block with specified key
cipher.init(Cipher.ENCRYPT_MODE, key256, CBC_SALT);
cipher.doFinal(data);
System.out.println("256-bit test: O.K.");
System.out.println("Testing of JCE restriction ended.");
cipher = null;
}
Best regards,
Ladislav Jech
470 Views
5 Replies

Anonymous
Not applicable
2011-02-08
02:09 PM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So I got deeper into this issue and found that there is also internal library in TOS at <TOS_DIRECTORY>/lib/java/ where are also loaded all required java libraries, I think this is done by talend engine. So I will try to replace the libraries here and see the result.
Ladislav
Ladislav
470 Views

Anonymous
Not applicable
2011-02-08
02:47 PM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm, it seems that correct libraries are loaded into the engine as following:
local_policy.jar file includes definition in default_local.policy
and US_export_policy.jar includes definition in default_US_export.policy
So in the engine folder correct libraries are loaded, but when I try to use keysize bigger than 128 bits, in both 32 and 64 version of TOS the result is still error:
This is really strange. I see the workaround just now only with create external jar in which I will package the required libraries directly and than this JAR include in Talend project.
Ladislav
local_policy.jar file includes definition in default_local.policy
// Country-specific policy file for countries with no limits on crypto strength.
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
and US_export_policy.jar includes definition in default_US_export.policy
// Manufacturing policy file.
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
So in the engine folder correct libraries are loaded, but when I try to use keysize bigger than 128 bits, in both 32 and 64 version of TOS the result is still error:
Starting job TestJCE at 20:42 08/02/2011.
connecting to socket on port 3700
connected
Exception in component tJava_1
java.security.InvalidKeyException: Illegal key size
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at routines.DesifrovatHeslo.testProstredi(DesifrovatHeslo.java:270)
at fnkv_ip.testjce_0_1.TestJCE.tJava_1Process(TestJCE.java:235)
at fnkv_ip.testjce_0_1.TestJCE.runJobInTOS(TestJCE.java:447)
at fnkv_ip.testjce_0_1.TestJCE.main(TestJCE.java:318)
128-bit test: O.K. - this is ok, this always run with standard libraries
disconnected
Job TestJCE ended at 20:42 08/02/2011.
This is really strange. I see the workaround just now only with create external jar in which I will package the required libraries directly and than this JAR include in Talend project.
Ladislav
470 Views

Anonymous
Not applicable
2011-02-09
03:51 AM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some progress, I have now the routine in Talend which checks for JCE Unlimited Strength Jurisdictions>
The result in Talend console is following>
So this is finally the fact, that still the standard cryptography libraries are used, in my case "AES : 128bit" tells me that max key size for AES cipher is 128bits. This is good to know, so I can continue with telling the engine use new libraries.
I am going now to install new JDK 1.6.0_23 and will continue to test this functionality in new JRE.
Ladislav
package routines;
import java.security.NoSuchAlgorithmException;
import java.security.Security;
import java.util.Set;
import javax.crypto.Cipher;
public class TestovatJCE {
public static void JCE(){
try {
Set<String> algorithms = Security.getAlgorithms("Cipher");
for(String algorithm: algorithms) {
int max;
max = Cipher.getMaxAllowedKeyLength(algorithm);
System.out.printf("%-22s: %dbit%n", algorithm, max);
}
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
}
}
The result in Talend console is following>
Starting job TestJCE at 09:43 09/02/2011.
connecting to socket on port 3384
connected
BLOWFISH : 128bit
ARCFOUR : 128bit
PBEWITHMD5ANDDES : 128bit
RC2 : 128bit
RSA : 2147483647bit
PBEWITHMD5ANDTRIPLEDES: 128bit
PBEWITHSHA1ANDDESEDE : 128bit
DESEDE : 2147483647bit
AESWRAP : 128bit
AES : 128bit
DES : 64bit
DESEDEWRAP : 128bit
PBEWITHSHA1ANDRC2_40 : 128bit
disconnected
Job TestJCE ended at 09:43 09/02/2011.
So this is finally the fact, that still the standard cryptography libraries are used, in my case "AES : 128bit" tells me that max key size for AES cipher is 128bits. This is good to know, so I can continue with telling the engine use new libraries.
I am going now to install new JDK 1.6.0_23 and will continue to test this functionality in new JRE.
Ladislav
470 Views

Anonymous
Not applicable
2011-02-09
06:40 AM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, finally I got this working. It seem to be a BUG if I compare the behavior of Talend and Eclipse. Where was the root cause??? I use Ubuntu, Debian based system, where you could install for some command it's alternatives. For example it supports have installed more than one JDK, and use:
- The one JDK manually selected
- The one JDK automatically selected based on alternatives JDK
So, even If I configure manually in Talend the compilation/execution environment (/myJavaEnvironmentPath/, it seems that the compilation part of Talend uses the one which is configured as default on my system itself, where the current JVM was linked to standard debian like folder /usr/lib/jvm/sun-6-jdk/....
So there is integrated the linux system tool called update-alternates where one could call it with --install option, etc....or to do it in some more user friendly way I installed tool called galternates (sudo apt-get install galternates) which is gnome panel based application where one could define all the system JAVA related object paths for:
- java
- java_vm - this is the one I think most important in my case, I defined the path as /development/Java/jdk1.6.0_23/jre/bin/java_vm, but I defined all here listed objects
- javac
- javadoc
- javah
- javap
- javaws
- jconsole
- jcontrol
- jdb
- jexec
- jhat
- jinfo
- jmap
- jps
- jrunscript
- jsadebugd
- jstack
- jstat
- jstatd
Well, after this, without needed any restart when I restarted the Talend, the result of my JCE Unlimited Strength Jurisdiction result is as following:
The result means that there is used the unlimited key length for all the ciphers listed...or more preciselly I could say that the max length is 2147483647bit, there is always a limit 🙂
So finally I got this working in a way, and will report a bug to check the Talend behavior against Eclipse.
NOTE: the bug link is at http://www.talendforge.org/bugs/view.php?id=18811
Best regards,
Ladislav
- The one JDK manually selected
- The one JDK automatically selected based on alternatives JDK
So, even If I configure manually in Talend the compilation/execution environment (/myJavaEnvironmentPath/, it seems that the compilation part of Talend uses the one which is configured as default on my system itself, where the current JVM was linked to standard debian like folder /usr/lib/jvm/sun-6-jdk/....
So there is integrated the linux system tool called update-alternates where one could call it with --install option, etc....or to do it in some more user friendly way I installed tool called galternates (sudo apt-get install galternates) which is gnome panel based application where one could define all the system JAVA related object paths for:
- java
- java_vm - this is the one I think most important in my case, I defined the path as /development/Java/jdk1.6.0_23/jre/bin/java_vm, but I defined all here listed objects
- javac
- javadoc
- javah
- javap
- javaws
- jconsole
- jcontrol
- jdb
- jexec
- jhat
- jinfo
- jmap
- jps
- jrunscript
- jsadebugd
- jstack
- jstat
- jstatd
Well, after this, without needed any restart when I restarted the Talend, the result of my JCE Unlimited Strength Jurisdiction result is as following:
Starting job TestJCE at 11:20 09/02/2011.
connecting to socket on port 3426
connected
BLOWFISH : 2147483647bit
ARCFOUR : 2147483647bit
PBEWITHMD5ANDDES : 2147483647bit
RC2 : 2147483647bit
RSA : 2147483647bit
PBEWITHMD5ANDTRIPLEDES: 2147483647bit
PBEWITHSHA1ANDDESEDE : 2147483647bit
DESEDE : 2147483647bit
AESWRAP : 2147483647bit
AES : 2147483647bit
DES : 2147483647bit
DESEDEWRAP : 2147483647bit
PBEWITHSHA1ANDRC2_40 : 2147483647bit
disconnected
Job TestJCE ended at 11:20 09/02/2011.
The result means that there is used the unlimited key length for all the ciphers listed...or more preciselly I could say that the max length is 2147483647bit, there is always a limit 🙂
So finally I got this working in a way, and will report a bug to check the Talend behavior against Eclipse.
NOTE: the bug link is at http://www.talendforge.org/bugs/view.php?id=18811
Best regards,
Ladislav
470 Views

Anonymous
Not applicable
2011-12-01
06:37 PM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hm, because some other people tried to use cryptography in Talend, I will post this demonstration of AES(Rijndael) with 256-bit key in CBC mode. This code you could tailore into Talend subroutine and use on your own. Maybe something like this will be implemented in a way of Talend component and you will be able to encrypt data from the design point of view...hope it helps...
Ladislav
To see the whole post, download it here
OriginalPost.pdf
Ladislav
package org.archenroot.crypto.aes;
/*
* @(#)EncryptString.java
*
* Summary: Application for encrypt string variables.
* AES(Rijndael) with 256-bit key in CBC mode.
* This is just a demonstration piece of code.
*
* Copyright: (C) 2009-2011
*
* Licence: MIT
* Copyright (c) 2011 Ladislav Jech
*
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restrictio
To see the whole post, download it here
OriginalPost.pdf
470 Views
