I am looking for open source JCE libraries that implement some of the more esoteric encryption algorithms so that I can study their implementation. I would be especially interested in ones that implement Identity Based Encryption (IBE) as published by Stanford.
Cryptix (not sure what state its in at the moment but it was high quality when I used it last):
http://www.cryptix.org
http://sourceforge.net/projects/cryptix
GNU Classpath also has their own JCE implementation, however, whether they support IBE is another story.
Related
Setup
Java doesn't offer out-of-the-box support for the JCE Unlimited Strength Policy Files
This prevents users from using AES-256, the largest key size of a widely-used encryption standard
Not including the policy files leads to many problems:
Unexpected exceptions
Unsatisfying workarounds:
Just install them
Use a different implementation
Use reflection that may violate the Java License Agreement
Breakage after JRE updates
Confusion after installation
And more!
All this noise leads to broken and/or buggy programs
Question
Why are these not provided and treated like a black sheep?
As it turns out, it's not strict crypto export laws, but simply that no one got around to it yet.
In fact, it's been planned for a long time to not have to jump through these hoops.
In Java 9, the ceremony will be condensed down to a one-liner: Security.setProperty("crypto.policy", "unlimited");
Now Unlimited cryptography enabled by default in the JDK
The JDK uses the Java Cryptography Extension (JCE) Jurisdiction Policy files to configure cryptographic algorithm restrictions. Previously, the Policy files in the JDK placed limits on various algorithms. This release ships with both the limited and unlimited jurisdiction policy files, with unlimited being the default. The behavior can be controlled via the new 'crypto.policy' Security property found in the /lib/java.security file. Please refer to that file for more information on this property.
See: http://www.oracle.com/technetwork/java/javase/8u161-relnotes-4021379.html#JDK-8170157
The US has restrictions on the export of cryptographic technology:
https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States
They used to be very strict -- cryptography was classified as munitions, and you could only download the full strength products from the US and other whitelisted countries.
Restrictions have eased up a lot since then, but some remain, and full strength JCE can't be freely distributed everywhere like the JRE, so it's a separate package.
Is Sun PKCS#11 provider supported on Android? Or can it be moved to Android somehow?
Thank you.
No. Sun==Oracle => copying bad :)
Seriously though, it is not available in Android and there is not standard PKCS#11 support either (although JB does use a proprietary PKCS#11 provider for some things). Not sure if the code is in OpenJDK, but if it is, you can try to port it. However, since it is unlikely that you actually need to use the full PKCS#11 API, it will be much easier to write JNI wrappers only for the functions you need (sighing, verifying, hashing, etc.).
Why do people use bouncycastle instead of Java Cryptography Extension? What is the difference?
BouncyCastle has many more cipher suites and algorithms than the default JCE provided by Sun.
In addition to that, BouncyCastle has lots of utilities for reading arcane formats like PEM and ASN.1 that no sane person would want to rewrite themselves.
Bouncy Castle is Australian in origin, and therefore is not subject to the Export of cryptography from the United States.
It is useful if you are outside the United States and you need to manage key sizes grater than permitted by such that restriction. In that case you are not permitted to use software from United States for that.
On server or desktop, I don't see any reason to use BC unless you have to deal with some legacy ciphers or formats not supported by Sun JCE.
However, many JREs don't come with a JCE provider, like on mobile or embedded environments. BC comes handy in such cases.
I'm trying to write an applet that would sign e-mail with S/MIME.
Obviously I want to make one small jar with only the required stuff.
Obviously the Java way of doing that involves having a huge sacred signed Bouncy Castle JCE jar around.
The question is: What's the easiest way of getting S/MIME without touching JCE and having it complain about "authenticating" "providers"? Maybe there is a S/MIME implementation that doesn't depend on JCE? Maybe it is possible to use Bouncy Castle S/MIME using their lightweight API without touching JCE? Maybe there is any other way?
It is obvious to me that nothing can prevent a pure-java open source crypto algorithms from working regardless of whether Sun approves, so it's not a question of theoretical possibility, rather: which way is the least painful?
Of course, I can always go ugly early by grabbing Bouncy Castle pure-java JCE implementation, renaming its packages to java.security1, and making any changes I want - but this way looks too painful right now.
UPDATE My current problem with using Bouncy Castle directly: I try to load keys from keystore, which involves using SecretKeyFactory, which in turn rejects my Bouncy Castle build.
BC S/MIME is written over the CMS package, so the question really devolves to modifying the CMS package so all the crypto is done using the light-weight classes.
Something similar has been done already, more-or-less successfully, for the .NET version of Bouncy Castle. We're trying (admittedly it's a slow process) to refactor the Java version so the CMS stuff can work with either JCE or lightweight. The same issue affects other parts of the BC API too e.g. the PKCS#12 keystore is built into the JCE provider, the OpenPGP package is written to JCE, etc. The .NET ports of these rewrote them to the light-weight API also.
Your problem is probably simpler than the general case though. Presumably you only need the CMSSignedDataGenerator and supporting classes. You probably don't need all the myriad variations of addSigner or generate. If you just decide on your digest/signature algorithms up front, then all the provider stuff will be easy to replace with hardcoded calls to specific lightweight implementations.
Instead of a keystore, maybe you could get away with just storing a single private key in a PKCS#8 file (PEM encoded perhaps). Similarly for the certificate.
It's pretty straightforward to sign messages without using JCE.
The real problem was reading PKCS#12 keys.
I did this:
* Copied JDKPKCS12KeyStore class over.
* Everywhere in it, replaced Security.getInstance() with bcProvider.getService().newInstance() (which returns Spi-s)
* In those Spi-s (in BC sources) made required methods public instead of protected.
It looks like a hack, but seems to actually work.
I need to programatically encrypt a directory of files, like in a .zip or whatever. Preferably password protected obviously.
How can I accomplish this, and WHAT IS the BEST encryption way to do it, if applicable?
Programming language doesn't matter. I am dictioned in all syntax.
How can I accomplish this, and WHAT IS
the BEST encryption way to do it, if
applicable?
tar and gzip the directory.
Generate a random bit stream of equal size to the file
Run bitwise XOR on the streams
Only truly secure method is a truly random one time pad.
I still say 7-zip is the answer. It hasn't been "cracked".
The OpenSSL library has a variety of block cipher implementations including the well-known AES. It has both a function-call interface (for use with languages like C/C++) and a program-call interface (for use in shell scripts). http://www.openssl.org/
4096-Bit (Open)PGP: 'Pretty Good' Privacy !
GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC4880 . GnuPG allows to encrypt and sign your data and communication, features a versatile key managment system as well as access modules for all kind of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. Version 2 of GnuPG also provides support for S/MIME.
libgcrypt:
http://www.gnupg.org/related_software/libraries.en.html
Edit:
BouncyCastle now has OpenPGP support.
http://www.bouncycastle.org/
Use AES. You'll find implementations in your favourite programming language by asking google for AES encryption + myfavouritelanguage.
If you're using .NET, why not use a free compression framework (http://www.icsharpcode.net/OpenSource/SharpZipLib/) that supports Encryption?