I am trying to use encryption algorithms from GNU-CRYPTO.
But whenever I try I get an: java.lang.SecurityException: JCE cannot authenticate the provider GNU-CRYPTO'
What is weird is the fact the I can use all hash functions from this package normally, but when I try to use ciphers I got those, for AES, DES, DESede...
Based on that I think the installation went fine. Also, when I use my code with other providers (BC,SUN), it works normally.
Could anyone help me with that.
algorithm="DES";
provider="GNU-CRYPTO";
generator = KeyGenerator.getInstance(algorithm); <-works
generator.init(randGenerator);
SecretKey key = generator.generateKey();
cipherEncryption = Cipher.getInstance(algorithm, provider); <- stops here
This is likely due to the fact that that project was integrated into GNU classpath. That means that the last signed provider was for 1.4. Up to 1.5 you had to create signed versions of your libraries for each Java version, so one for 1.4 is probably not compatible with 1.5 and higher (check for instance the bouncy class library, which has separate downloads for each version of Java up to 1.5). Furthermore, the certificate may have expired.
Please use cryptographic libraries that are actually maintained. There should be no need for GNU crypto in the first place.
Related
My program is a simetric crypter that uses a key lenght of 256. When I use it on a computer that didn't have the JCE installed (for no key lenght), it crashes with the following error:
java.security.InvalidKeyException: Illegal key size or default parameters
So it is because the computer didn't have the extension that allows to use this keysize.
Is there any way to put the java unlimited strength extension with my program for use it without install? Or can I open a dialog for install it automatically?
In other hand, there are a better solution for do an AES encryption with a 256 key? Maybe another API allows me to do it without adding any extension? (like bouncy castle).
JCE Unlimited Strength can be downloaded from the Oracle website. (Or at least, I can download it in Australia.)
However, you first need to agree to the Oracle Binary Code Licende for Java, and clause 7 says this:
"7. EXPORT REGULATIONS. You agree that U.S. export control laws and other applicable export and import laws govern your use of the Software, including technical data; additional information can be found on Oracle's Global Trade Compliance web site (http://www.oracle.com/us/products/export). You agree that neither the Software nor any direct product thereof will be exported, directly, or indirectly, in violation of these laws, or will be used for any purpose prohibited by these laws including, without limitation, nuclear, chemical, or biological weapons proliferation."
So to answer your questions about JCE
Is there any way to put the java unlimited strength extension with my program for use it without install?
I'm not a lawyer, but I think that the Oracle license says that you can only use the JCE code (and that includes distributing it in your product) if your usage conforms to US export law. Be aware that crypto software is specifically restricted.
Or can I open a dialog for install it automatically?
That is unclear, both legally, and technically.
Maybe another API allows me to do it without adding any extension? (like bouncy castle).
Bouncy Castle is also covered by US export laws. Furthermore, in the Bouncy Castle FAQs, FAQ #1 says that key lengths in Bouncy Castle's Java SE compatible crypto provides are governed by the same mechanism (and policy files) that JCE uses. However FAQ #10 says:
"At the time of writing (16 May 2007) Bouncy Castle is approved classified under ECCN code 5D002 and approved for export under License Exception TSU."
I also looked up "License Exception TSU" and I found that it is defined in the Exceptions to the Export Administration Regulations (EAR) as:
"§ 740.13 TECHNOLOGY AND SOFTWARE UNRESTRICTED (TSU)
This license exception authorizes exports and
reexports of operation technology and software;
sales technology and software; software updates
(bug fixes); “mass market” software subject to
the General Software Note; and encryption
source code (and corresponding object code) that
would be considered publicly available under
§734.3(b)(3) of the EAR."
And so on.
It looks promising, especially for an open source product, but I would still advise getting advise to a real expert; i.e. a professional with appropriate legal training.
Good news, everyone!
Starting with Java 6u181, 7u171 and 8u151 you will be able to programmatically change the policy with a call
Security.setProperty("crypto.policy", "unlimited");
If you have a security manager installed you will need to configure it to allow setting security property. More info in JDK-8169716.
Even better is that in Java 9, and also starting with future Java 6u181, 7u171, 8u162 releases the unlimited crypto will be enabled by default! More info in JDK-1870157
I've encrypted a file using Bouncy Castle API. I've successfully decrypted that file using the same API.
However I cannot decrypt the file using PGP command line
No error messages are shown but the decrypted file is not being generated:
C:\pgp-cli>pgp arquivo-cripto-cast5-bin.pgp
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: contine
2048-bit RSA key, Key ID 0x150AAE5B, created 2015/03/26
Key can sign.
Could it be a compatibility issue?
PGP 6.5.8 is horribly outdated, a lot changed in cryptography since then. There is a bunch of ways to introduce incompatibilities with this old PGP version, and it's hard to tell what exactly is the problem. Since that old version, new ciphers (both symmetric and assymetric), hashing and I think even compression algorithms have been introduced.
If you do not want to buy a newer version, consider using GnuPG which is free and mostly even compatible with PGP's arguments (and probably has much broader usage than the good old PGP, which is owned by Symantec at the moment). A readily built GnuPG package for Windows is available on GPG4Win.
I have seen that AES 256 Encryption Decryption works on Java 6 and above.
How can i achieve the same thing in Java 5 (apart from policy files)
The BouncyCastle library has support all the way back to 1.4. It includes AES256, and as long as you don't use it as JCE provider, I think you can use it without policy files.
That said, the default Java 1.5 JCE (Java Cryptography Extension) does include AES256. As you noted in your question, you would need to deploy an unlimited policy file to actually use the 256-bit algorithm. This is unavoidable, but shouldn't be that difficult. The bouncycastle link above tells you how to do it.
I want to use a HSM (hardware security module) to create a signature of a XML file. I did a bit of research and am now a bit confused, though.
Can you please clarify those questions:
What is meant with a key handle in JCE? I have read about it, that it is just a handle and the key is stored somewhere else. How can that be? From my understanding I either load the key into memory and use it, or the signing is done completely by a HSM and I only get the result, right?
Does the PKCS#11 standard define a way so that the signature is generated in the HSM? I've read about tokens, but I am not sure about signing.
The featurelist of my HSM states JCE and PKCS#11 separately. What does that mean?
I thought PKCS#11 is a standard, and JCE defines classes to use that standard. Does JCE specify its own protocols?
What is meant with a key handle in JCE?
A key handle (in JCE, PKCS#11, or most other cryptographic APIs) is simply a reference that enables you to use a key without seeing its actual value. That is good: you can have the key permanently stored in a secure place (e.g. an HSM) with the assurance that nobody will be able to copy it and run away with it - as it may happen if the key is the application space. Unlike a physical safe though, you can still perform cryptographic operation without running any security risk of key leakage.
Does the PKCS#11 standard define a way so that the signature is generated in the HSM?
PKCS#11 is a C API for cryptographic tokens. A token is a PKCS#11 abstraction for any device or program that offers services described by such API. The API defines which operations you can perform using the objects inside the PKCS#11 token: some objects are non sensitive, and can be extracted (e.g. public keys); some others are sensitive and can only be used, via handles.
If you have a handle to an object that supports signing, you can use the C function C_Sign to ask the token to authenticate some data provided by your application. The key does not leave the HSM.
The featurelist of my HSM states JCE and PKCS#11 separately. What does that mean?
Your HSM supports JCE in the sense that it comes with a native library that qualifies as a Cryptographic Service Provider.
It supports PKCS#11 in the sense that it comes with a native library that offers a C PKCS#11 API.
I thought PKCS#11 is a standard, and JCE defines classes to use that standard. Does JCE specify its own protocols?
Indeed PKCS#11 is a standard; but it is not directly usable by languages other than C. You need a mapping layer that translates it into something compatible to your language. A PKCS#11 library (and the physical tokens that it abstracts) can be mapped to a JCE provider.
However, a JCE provider may have nothing to do with PKCS#11.
I need an java RC5 encryption and decryption algorithm.
The JCE includes support for RC5 but Sun has not implemented RC5 in any of their providers. The Bouncycastle provider, on the other hand, does include RC5. So if you just add the bouncycastle provider you should be able to use RC5 through the JCE (e.g. Cipher c = Cipher.getInstance("RC5/CBC/PKCS5Padding");)
However, just because you can get it for free does not mean you can legally use it for free. For example, in the U.S. you would need to obtain a license from the RC5 patent holder.
EDIT: The RC5 patent has expired in the United States.
The JDK comes with a JCE provider supporting RC5. See http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html and look for the explanations on the Cipher class to get you started.
Also look at the RC5ParameterSpec class.