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.
Related
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.
We have an existing java library code using Bouncy Castle, we want to be able to use our library on Android without maintaining 2 versions of the code.
Using Bouncy Castle on Android is always complicated and one of the common solution is to use Spongy Castle, which is a simple repackaging of Bouncy Castle (same classes with same signatures but in a different package and without hierarchical relationship between the 2 packages).
My question is whether it is possible to use AspectJ on our existing library to replace Bouncy Castle by Spongy Castle ?
I know that AspectJ is not necessarily intended for this task but as we are already using it, it would be nice to be able to integrate this implementation switch with the others aspects. If it's not possible, do you know another way (tool) to do it ?
Thanks!
I'm looking for a java-based encryption library for Android. I am aware of the built-in encryption that Android offers. Don't want it. Google broke compatibility from one OS to another. My app cannot rely on that. I also looked at Bouncy Castle, which is what Android uses internally but modified. The footprint however is pretty big at around 1.5 meg. Spongy Castle is available but is just a wrapper for Bouncy Castle with the same footprint.
Anyone aware of any other libs?
From a Java perspective, pretty much the only two games in town are the built-in JCE providers and BouncyCastle. Since Oracle's JCE stuff isn't in Android, you either get to use the modified BoucnyCastle built-in, or SpongyCastle.
There are a couple of other options out there (GNU has one as a part of their classpath libraries, which would probably fail your footprint requirements), but honestly, I would be very skittish about using another crytpography library. They are used by such a small subset of people (pretty much everyone who isn't using the built-in JCE providers is using BouncyCastle) that they are unlikely to have been rigorously reviewed for security, and for that reason you should probably avoid using them.
If you are concerned about api breaking within the built-in APIs, I would just stick with SpongyCastle. 1.5mb is honestly not that much of a footprint.
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 am currently upgrading an application that generates OpenPGP messages to be FIPS 140-2 compliant. Currently I generate PGP messages that use RSA/AES-256 encryption which are both approved algorithms using BouncyCastle and its OpenPGP provider. I am no longer able to use BouncyCastly since it is not FIPS 140-2 validates, so I am looking at the BSAFE library from RSA.
This library doesn't have the high-level abstraction to let you generate an OpenPGP message directly. Does anyone know of a library that can use an existing JCE provider (like my BSAFE library) capable of generating OpenPGP messages? I'd really like to avoid having to implement the OpenPGP spec myself, as that seems like it would be quite time consuming. Alternatively any suggestions for other ways to format my encrypted files?
Thanks in advance for any input!
After much research it seems that there is no way to do this without implementing the OpenPGP format yourself. However the Cryptographic Message Syntax seems to be a suitable replacement.
There are major differences between S/MIME (Cryptographic Message Syntax) and OpenPGP.
http://mozilla-enigmail.org/forum/viewtopic.php?t=67
Mainly, S/MIME exchanges keys in terms of certificates (which must utilize a certificate authority, limited to 1024 bit, and expires after 1 year), while OpenPGP uses PGP keys (can be exchanged peer-to-peer, or utilize a free keyserver, or host your own keyserver).
FIPS 140-2 doesn't apply to protocols like SSL, PGP, S/MIME, or SSH. Those are security protocols that use cryptographic algorithms like RSA and AES. (Commercial crypto vendors aren't likely to point out this distinction, however).
FIPS 140-2 lists approved algorithms. It also specifies testing criteria for "cryptographic modules" that implement these algorithms. But, it doesn't say anything about the application of these algorithms.
So, you can use BouncyCastle's PGP provider. Instead of installing Bouncy Castle as a crypto-provider, install your FIPS 140-2–certified implementation. Bouncy Castle's PGP will use the preferred crypto provider for its underlying cryptographic algorithms. You can use their S/MIME support in the same way.