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!
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.
I have the following way of generating a self signed certificate using the class CertandKeyGen.
CertandKeyGen cert = new CertandKeyGen("RSA", "SHA256withRSA);
cert.generate(size);
..
X509Certificate certificate = cert.getSelfCertificate(name, validity);
Since these are internal APIs from keytool, I am looking at a similar approach using java.security.* APIs.
I want to know if this is possible currently. If yes, what are those APIs? I dug around but I am unable to find anything about it. I am aware of bouncy castle APIs (X509V3CertificateGenerator) but I do not want to use third party APIs.
Thanks.
At present, I do not believe that the generation/signing mechanisms that are used in keytool are part of the public API for Java.
I have implemented a very simple CA/Signing mechanism utilizing BouncyCastle for testing purposes.
I don't think you're going to be able to do this without a 3rd party api or implementing a very significant amount of code on your own.
I was reading a tutorial about java encryption using the DOM, and I cam across a strange case of a package javax.xml.crypto.enc.* not existing. I had heard that not all packages were shipped with the standard JDK, and instead needing to be downloaded as separate modules and imported into the project, is this one of these cases? If so, where can I download it?
I just did some research about the package, and it turns out that it was a part of, the now withdrawn, JSR-106: XML Digital Encryption APIs. http://jcp.org/en/jsr/detail?id=106
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.
Right now I'm using BinaryNotes to parse ASN.1 files for use in a Java project. It takes an ASN.1 definition and produces Java class(s) that let me manipulate ASN.1 files.
I've hit a wall with extension markers (...) because it doesn't support them. The source forge project page says they're coming in the next release, but the last release was nearly 2 years ago so I fear the project is dead.
Can anyone recommend an easy (and $free) replacement that does a similar thing and does support extension markers?
Have you tried Bouncy Castle.
From the site:
Bouncy Castle Crypto APIs for Java consist of the following:
A lightweight cryptography API.
A provider for the Java Cryptography Extension and the Java Cryptography Architecture.
A clean room implementation of the JCE 1.2.1.
A library for reading and writing encoded ASN.1 objects.
...
Binary Notes is unsupported, but you can try jASN1 from OpenMuc. It appears to be based in part on Binary Notes and is currently active. The jASN1 libraries are available for download on their home page, and on JCenter and Maven Central under the group org.openmuc