I get why java.security.Security has an addProvider method - because Java has multiple providers that can provide stuff like javax.crypto.Cipher.getInstance() can use (sun.security.provider.Sun, org.bouncycastle.jce.provider.BouncyCastleProvider, etc).
But why does org.bouncycastle.openssl.jcajce.JcaPEMKeyConverter have an addProvider method? Given the namespacing being used I find it hard to imagine that any "provider" other than BouncyCastle would provide a drop in replacement...
It's correct that the API is not designed on the assumption that the user has to use BouncyCastle for the provision of cryptographic services - and a ready example of this is people using a FIPS provider, such as BCFIPS.
One small correction though to the preceding answer, there is no license fee or similar for the BCFIPS Java provider and as one of the members of the project I'm more than a little disturbed to see someone stating that. I would be curious to know where that was heard from.
We do have a support program for FIPS and non-FIPS users and it does provide early access to the in-progress FIPS releases as part of it and that does cost (that's how we fund everything). However, the actual released FIPS jars, once published on bouncycastle.org are licensed under the BC license, which is basically the MIT X11 license, like all our other published work. I hope this clears up the confusion.
I don't know what 'namespacing' you think is being used. JcaPEMKeyConverter uses JCA to implement the crypto operations it needs, and it can use any JCA provider that provides the needed operations; nearly the whole point of JCA is that providers use the same API (or technically SPI, Service Provider Interface) so that you can selectively use different providers for the same operation(s).
Some, perhaps most, of the operations in bcpkix bcpg and bcmail libraries can use either JCA API (using any suitable JCA provider(s)) or Bouncycastle's own private API (using only Bouncy code), e.g. org.bouncycastle.pkcs.PKCS12MacCalculator[Builder] are interfaces with interchangeable implementations org.bouncycastle.pkcs.bc.BcPKCS12MacCalculator[Builder] and org.bouncycastle.pkcs.jcajace.JcePKCS12MacCalcuator[Builder]. (Bouncy isn't as careful as one might wish about distinguishing JCA from JCE in names consistently.) However, JcaPEMKeyConverter comes only in the JCA form.
It is true someone who has Bouncy add-on libraries will often have and be able to use the Bouncy provider as well, but not always. For example, US federal government systems are required to use certain cryptographic functions (mostly primitives) that are validated under FIPS140 (currently at revision -2, soon -3), and while Bouncy does have a FIPS140 implementation, using it commercially requires payment, while if you are using e.g. IBM Java on certain IBM systems it has providers (different from the common Sun/Oracle/OpenJDK ones) that are FIPS140 validated at no additional charge.
Related
I have a case where I need to encrypt some files using OpenPGP. I am using Bouncy Castle to do so.
As I understand it Bouncy Castle encryption can be used in java in two ways:
I add Bouncy Castle as a provider and continue to use the standard Java libraries.
I use the classes specified in the Bouncy Castle library directly.
I wanted to know the pros and cons of both the ways and which method is recommended.
Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception when I execute the following line:
PGPEncryptedDataGenerator encGen =
new PGPEncryptedDataGenerator(
new JcePGPDataEncryptorBuilder(PGPEncryptedData.CAST5).setWithIntegrityPacket(withIntegrityCheck).setSecureRandom(
new SecureRandom())
.setProvider("BC"));
As I understand it Bouncy Castle encryption can be used in java in two ways:
I add Bouncy Castle as a provider and continue to use the standard Java libraries.
I use the classes specified in the Bouncy Castle library directly.
I wanted to know the pros and cons of both the ways and which method is recommended.
The Java JCA is a better designed and certainly better documented API. It has better defined exception handling, more up to date parameter handling (ByteBuffer).
Furthermore, through the use of the provider abstraction, it can be enhanced not just with software based providers such as Bouncy Castle, but also with platform functionality and hardware providers. So if you program against the JCA you'll be rewarded with a more flexible runtime.
On the other hand the lightweight crypto API is a relatively low level API that provides a lot more functionality in a relatively well structured fashion. If you use it you're basically choosing Bouncy Castle as your sole provider of functionality. Bouncy Castle contains specific implementations in Java code only, which means that you won't get (much) hardware support.
Bouncy Castle's lightweight API doesn't have jurisdictional restrictions (such as 128 bit AES keys). So you can use it for your own protocol if you want to work around those restrictions (don't get me started on the reason why these restrictions are there in the first place if you can download an equivalent library without issue).
Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception (...) ?
The Bouncy Castle PGP functionality is actually build upon the JCA; it's that simple. If it wasn't you could not use Java keys or other (platform or hardware) cryptographic functionality.
A lot of other software components also assume the JCA to be used. You cannot simply plug the lightweight API into an existing protocol implementation.
In my understanding java.rmi is a specification.
How do I know what particular implementation of java.rmi am I using when I'm developing using that API.
Also is there a limit on the maximum number of threads that
are started on an RMI server ?
You use the implementation by the provider of the JDK. Therm isn't a provider architecture like there is in JNDI, NIO, JCA, etc.
The RMI Specification doesn't mention any limit on threads.
I would hardly call RMI a "specification". It is a quite Java specific serialization implementation; and it's whatever implementation matches the JRE version you are running. I would advise not randomly mixing and matching JRE versions between client and server when RMI is in use. Nor would I advise serializing POJOs using exotic features that don't exist in older VMs.
Though it's not "specified", I have reverse engineered an almost complete RMI implementation for C# before (for use with Spring/Hibernate based servers from WPF), but I don't know of anybody that uses such non JRE implementations in the real world. You get stuck with RMI just to communicate with J2EE systems in some cases. But, if at all possible, you should use something more reasonable like ProtocolBuffers/Thrift/Avro/Hessian/Parqet, etc. Those have real "specifications" with a versioned wire protocol and IDL compilers for multiple platforms; which was absolutely not the case at the time I did that for RMI.
RMI has other problems that I would categorize as security issues (ie: you spell out a class name in the serialization stream and it will call a no-arg constructor to create a class of that name). Its design also isn't very good for situations where object graphs can get large. (In particular, you can make the stack grow really large during deserialization.)
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 want to replace PostgreSQL encryption function ‘pgp_sym_encrypt’ and ‘pgp_sym_decrypt’ mechanism with HSM (hardware security module). Can i implement it to replace existing algorithm with HSM.
If your client is paying you to find this out, it'd be nice if you would do some research and work on it, not just ask Stack Overflow.
The pgp_sym_ functions are in contrib/pgcrypto/pgp-pgsql.c. They're wrappers for decrypt_internal, and in turn around the functions exposed in pgp.h and implemented in the pgp*.c files.
You'll see that pgcrypto has its own OpenPGP implementation. That means it's not using GnuPG as a library, and therefore cannot simply use GnuPG's support for hardware security modules directly.
If you want support for HSMs, you will need to implement it yourself in the pgcrypto extension. You may be able to use libgcrypt and GPGME functions to help you out, and/or functionality in OpenSSL. It depends on what HSM you're using; it might just a client library that does most of what you want.
It may be simpler, if your HSM has a client library that has functionality you want, to wrap that with PostgreSQL user-defined functions and expose it to SQL as a new contrib module.
Either way, you will have to do a lot of reading and a lot of research. You will need to know the C programming language and be comfortable working with it. You will need to understand how user-defined functions in PostgreSQL work. If you can't manage any of that, you'll need to subcontract the work to somebody who does, give them access to a sample of the HSM in question, and pay them for their time. (No, I'm not fishing for work, I already have too much).
Many HSM's can be programmed some of them will undoubtedly be both Turing complete and have enough memory to perform your encryption function (whatever that may be). So the answer is "yes".
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.