Monday, March 28, 2016

Encrypting and Decrypting with Spring

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities. It "was decided" that we'd be doing AES with a key-length of 256, and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet!

The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE in order to do 256 bits. It's a fascinating story, the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them.

Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password and salt. It's called encryptomania. Note that in order to run it you'll need the JCE (for now, see below).

Screenshot from encryptomania, my little crypto GUI

Some thoughts on the JCE

So at one level, Spring crypto has a problem in that they force all users of the library to patch their JRE. This makes it pretty much impossible to deploy in an environment where you don't have complete control of the environment (computers w/o root or admin-access, and PaaS). So it would be cool if they would support 128 bit key-length, and I've started a patch to fix just that.

The other problem here is that Oracle doesn't just build the JCE into all the JREs. I mean, a malevolent programmer won't have any problems downloading the JCE into a country where it is not allowed, so it's more of a formal thing. And still if they would change the default here, it would take years for the change to propagate into all the data-centres around the world. I think we're better off betting on some other kind of encryption (maybe a 128 bit Twofish cipher out of Bouncy Castle) to become more trusted than the one provided by Oracle.

At the same time it is all a bit silly for your average non-critical webapp, as 128 bit AES is considered to be practically impossible to break in the foreseeable future.

Tuesday, March 15, 2016

Replacing Boxen with Vanilla Puppet (for setting up a new mac)

I recently got a new MacBook at work and decided to overhaul my personal setup routine. Last time I tried an early version of Boxen, and although I was pretty happy with it there were a few things that bothered me. It is very opinionated, and I had a hard time stopping it from overwriting my .gitconfig and things like that. It also dragged in a series of dependencies I didn't feel the need for, and made Homebrew a bit weird by installing it in the non-standard location /opt/boxen/homebrew.

Since Boxen is based on Puppet, and I've used plenty of Puppet on Linux, I wanted to simplify things a bit and see how far standard Puppet on OS X would get me.

Warning! Make sure you don't install puppet using brew! It'll install an old version which is not trivial to uninstall.

It's fairly straight forward to install Puppet on a Mac, but since there is no standard package manager, like there's yum or apt on Linux, you have to set it up with a provider, in our case: Homebrew. I installed Homebrew manually at this point, but I think you could actually have Puppet do it for you.

Next, we have to install a puppet module for Homebrew. I found found a good one here by Kevin James (I tried the gildas and halyard ones first, but kept running into problems with them).

As Puppet goes, it has to be executed as superuser:

    sudo puppet module install thekevjames-homebrew

and it depends on the Puppet standard library:

    sudo puppet module install puppetlabs-stdlib

Now we're ready to fire away and apply a puppet file defining our packages:

    sudo puppet apply puppet-mac.pp

As an example, consider my own puppet-mac.pp - note how I've got various kinds of packages:

  • normal packages, these are built from source by Homebrew
  • casks, which are Homebrew's notion of pre-built binaries
  • gems, for those weird pieces of software that are not available via Homebrew
People who enjoy Boxen will probably not see the big point of going this way, but I think it feels easier and more elegant. It also reduces the discrepancies between my Linux and Mac setup.