Networking and Unix

Updated Encryption Routines in TemplateFx v2.54

 August 12th, 2016Aug 12th, 2016        0

In the spirit of public disclosure as all encryption/decryption routines should be publicly available for scrutiny, the following article includes the updated routines which are within TemplateFx v2.54. Previously TemplateFx was using AES-128 for encryption and HMAC-SHA256 for authentication. The keys were being derived using PBKDF2 with HMAC-SHA1 using 100,000 iterations. However, I wasn’t completely happy with the following bits:

  1. I was using PBKDF2 with HMAC-SHA1 as the PRF (pseudo-random function) which didn’t provide enough output for my HMAC-SHA256 key (160 bit output instead of 256 bit). This also meant I had to run PBKDF2 twice, which was a bit messy – once for my AES-128 key and once (with a different salt) for my HMAC-SHA256 key.
  2. My HMAC wasn’t across all the data – I was just including the ciphertext, which means someone could have changed my encryption salt to manipulate my decrypted ciphertext while still passing the HMAC authentication check.
  3. There was no support for AES-256 if the user had decided to install the “Java Cryptography Extension Unlimited Strength Jurisdiction Policy Files”.



AES Encryption with HMAC Integrity in Java

 April 19th, 2015Apr 19th, 2015        14

UPDATED: 12th August 2016

I recently came across a requirement to provide password based encryption and decryption of data in a Java program. I initially assumed I just needed to pass my data through some internal Java “encrypt (plaintext, password)” type function and all would be fine. Unfortunately I found it isn’t quite as simple as this and there are quite a few pitfalls you need to overcome if you want to do this securely and properly.

I also wanted to work within the limitations of Java and only use native libraries (e.g. “javax.crypto”), which rules out the popular Bouncy Castle cryptographic library – rolling your own crypto functions is also a very bad idea (repeat “very bad idea“) as even the experts can get it wrong sometimes. I also wanted to ensure it worked with Java 7, which rules out some of the newer more modern modes of AES like GCM (Galois/Counter Mode).


General Cryptography Java

Tracking Downloads with Google Analytics

 April 27th, 2014Apr 27th, 2014        3

Google Analytics does a very good job at tracking page views out of the box, but requires a bit more technical expertise to successfully track download events. There are lots of different WordPress plugins available, but they all seem very complicated and none that seemed to track download events out of the box. With this in mind I decided to come up with a simple solution that only requires a single line to be included in your header section for it to track page views and download events.


General Google Analytics JavaScript

The Impeding Death of Java on MacOS

 April 22nd, 2014Apr 22nd, 2014      

It seems Apple’s long term goal is to eventually drive a wooden steak through any technology that doesn’t adhere to their vision of the future. Before they had finished putting the final nails on the coffin of Flash, they have moved onto Java and placed it firmly within their crosshairs. This hasn’t been totally unwarranted though, Oracle has had a lot of bad press recently (and Sun historically) with respect to Java security, which has resulted in Apple disabling Java in the browser on numerous occasions until exploits and vulnerabilities have been patched – a strategy that some think was drastic, but it places pressure on vendors to fix things quickly and in this case, it appears to have worked.


General Java MacOS Security

Self-Signed CA with CRL for Java Code Signing

 April 6th, 2014Apr 6th, 2014        1

I am going to start off by saying that since Java 7 Update 51, that using self-signed certificates is pretty much a waste of time for Internet deployments. With Update 51, Oracle has beefed up the security aspects of Java, which now blocks self-signed JAR files from being run via the web – even for applications which only want to run within the restricted “Sandbox”.

There are a couple of ways around this. The first is to reduce your security settings from the recommended (and default) High option to Medium (in the Java Control Panel), which allows self-signed JAR files to be executed after presenting a scary warning message (for the time being anyway). When set to High you don’t even get a choice, it was just blocked. The second is to get your clients to import your self-signed root certificate into their trust store – this approach could work within a closed or corporate environment but won’t on the Internet. The third, and recommended approach, is to sign your JAR file with a code signing certificate which has been signed by a trusted CA, but this will set you back a few pennies.


General CA Java OpenSSL

1 2 3