Monthly Archives: June 2010

Saving and restoring Singletons

The Singleton pattern is one of my most favorite patterns. I use it for writing services, as controller in MVC and sometimes as settings storage.
Here’s the code how to create a Singleton in Java:

public class Singleton {
   public static Singleton instance = new Singleton();

   public static Singleton getInstance() {
      return instance;

   private Singleton() {

Sometimes you want or have to restore a Singleton and this is where it can get problematic. You could try to expose the internal state of the Singleton via a Memento but this will generally cause big troubles.

Since the idea behind the Singleton is that it only exists once and shows only one state to all classes, it does not make sense to give anyone the possibility to save and restore it.

But what if you want to keep the state of a Singleton over multiple sessions?
The best way is to load the old state when the Singleton is created. This means this will happen only once, usually the first time the Singleton is accessed. Simply build a private load function in your singleton that you call in the constructor. Inside the load function you can then read data from a file, database, de serialize an object etc. and set all private properties you need to the old state.

Now, we have a Singleton that can load it’s old state, but how do we save it?
We add a public function save to the Singleton. Every time that function is called, we save the current state of the Singleton so that we can read it later again. There is just one thing you must not forget: Thread safety.
In java, you can do this quite easy:

public void load() {
   synchronized(this) {
      // write data to the database etc

This will block any access to the object until the critical section is done.

However there is still a big question: When to save?
Unfortunately, this depends heavily on the application. You could either save whenever someone sets something (only do this when this does not happen often), schedule it (this might still cause a loss of data) or simply call it manually whenever you think the time is right.
I usually do it manually since the other options do not appeal to me. I usually only save once, when I shut down the Application, right before the exit command.

Did this help? Then please consider donating.
I do not need nor want money instead buy me some music so I can have fun while writing another guide! CDs (Amazon)
Alternatively, I am also totally into books. Books (Amazon)

Encrypting and decrypting large data using Java and RSA

Encrypting large data using Java and RSA is not a lot different to encrypting small data, as long as you know the basics.

Our goal is to encrypt a String of arbitrary length, send it over the Internet and decrypt it again on the other end. We will not discuss key exchange here since that is a rather trivial task.

What we need first is a KeyPair. Where you get it from does not matter in the end – Here we will create one on the fly.

KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
this.keypair = kpg.generateKeyPair();

Now that we have our KeyPair we also need a Cipher that works with our Keys. I used a plain RSA Cipher without specifying padding etc.

this.cipher = Cipher.getInstance("RSA");

Next we would like to have 2 functions that can encrypt and decrypt. Here we will face 2 big problems:

  1. Ciphers do not use Strings, they use byte arrays.
  2. block ciphers cannot encrypt arbitrary long byte arrays directly.

Both of those points seem rather trivial to solve – but the devil is in the details.
First of all we have to understand that Strings and Strings can be different things. At the end of the day, a String represents the encoding of quite a lot of 0s and 1s. Even if our bytes are set in stone that does not mean that byte -> String -> byte will give us identical byte arrays.
Question: Why not?
Answer: Encodings!
I’m pretty sure you have heard about UTF-8 somewhere so far. UTF-8 only defines how a series of bytes is mapped to a char. The problem is that there are quite a lot of byte patterns that do not always make sense (in the context of UTF-8) or are not really standardized. This is why German letters like öäü etc or for example Japanese symbols sometimes get replaced by something else like a box, star etc. We have all seen it.
So we will need a better representation than “normal” Strings. Especially for transferring the String (or storing it or … Well basically anything) we want a representation that will keep the correct byte message and supports byte -> String -> byte operations.
The 2 most common ways are to use base 64 encoding or hex encoding. In my example I will use Hex encoding since I had to call REST services with encrypted Strings and base 64 encoding inserts CR/LF markers when it seems fit – something you do not really want in URLs.
But, before I go on, let’s have a look at the encrypt and decrypt functions:

public String encrypt(String plaintext) throws Exception{
	this.cipher.init(Cipher.ENCRYPT_MODE, this.keypair.getPublic());
	byte[] bytes = plaintext.getBytes("UTF-8");

	byte[] encrypted = blockCipher(bytes,Cipher.ENCRYPT_MODE);

	char[] encryptedTranspherable = Hex.encodeHex(encrypted);
	return new String(encryptedTranspherable);

First we init the cipher with encryption mode and our public key. We could also have gotten the key from somewhere else, the only important part is that you need a cipher and a key that work together or you will get exceptions.
After that, we convert the plaintext to a byte array. You can see that we assume the String to be in UTF-8. This could be skipped but might lead to side effects while recreating the string later. I included the UTF-8 for safety reasons.
Next we call the function blockCipher, which does all the magic of encrypting in blocks (we will come to that later).
Now we encode our new, encrypted byte[] into a Hex based String. For this purpose I used the org.apache.commons.codec.binary.Hex class. If you do not want to import that for any reason, have a look at the source code here:

The String is now ready to be saved to the disk, transferred over the Internet or even sent via mail.

Decryption is much the same, just the other way round. This time we go from HexString -> byte[] -> String. Note that we again create a String that is UTF-8 based at the end.

public String decrypt(String encrypted) throws Exception{
	this.cipher.init(Cipher.DECRYPT_MODE, this.keypair.getPrivate());
	byte[] bts = Hex.decodeHex(encrypted.toCharArray());

	byte[] decrypted = blockCipher(bts,Cipher.DECRYPT_MODE);

	return new String(decrypted,"UTF-8");

So far so good, but what about the voodoo in blockCipher? Here’s the source:

private byte[] blockCipher(byte[] bytes, int mode) throws IllegalBlockSizeException, BadPaddingException{
	// string initialize 2 buffers.
	// scrambled will hold intermediate results
	byte[] scrambled = new byte[0];

	// toReturn will hold the total result
	byte[] toReturn = new byte[0];
	// if we encrypt we use 100 byte long blocks. Decryption requires 128 byte long blocks (because of RSA)
	int length = (mode == Cipher.ENCRYPT_MODE)? 100 : 128;

	// another buffer. this one will hold the bytes that have to be modified in this step
	byte[] buffer = new byte[length];

	for (int i=0; i< bytes.length; i++){

		// if we filled our buffer array we have our block ready for de- or encryption
		if ((i > 0) && (i % length == 0)){
			//execute the operation
			scrambled = cipher.doFinal(buffer);
			// add the result to our total result.
			toReturn = append(toReturn,scrambled);
			// here we calculate the length of the next buffer required
			int newlength = length;

			// if newlength would be longer than remaining bytes in the bytes array we shorten it.
			if (i + length > bytes.length) {
				 newlength = bytes.length - i;
			// clean the buffer array
			buffer = new byte[newlength];
		// copy byte into our buffer.
		buffer[i%length] = bytes[i];

	// this step is needed if we had a trailing buffer. should only happen when encrypting.
	// example: we encrypt 110 bytes. 100 bytes per run means we "forgot" the last 10 bytes. they are in the buffer array
	scrambled = cipher.doFinal(buffer);

	// final step before we can return the modified data.
	toReturn = append(toReturn,scrambled);

	return toReturn;

I will not comment the source again, just go ahead and read it. The most important part is maybe this: int length = (mode == Cipher.ENCRYPT_MODE)? 100 : 128;
This part will tell the code wheter we chunks that are 100 bytes long or use 128 long chunks.
Why do we need that?
RSA is a block cipher. No matter how long (or rather: short) the input, it will produce a 128 byte long output. That explains the 128.
But why the 100? Could we not just use the whole byte array?
No we can’t. Most guides will not tell you this part at all since the authors forget that plaintext Strings can get quite large. No block cipher can ever encrypt a bitstring longer than the maximum block size. That’s why they are called block ciphers (opposed to stream ciphers that encrypt bit by bit or byte by byte).
If you ever find a class that can take arbitrary long input, uses a block cipher and generates an output, you can be 100% sure that the block ciphering is done internally.
So what we do is:
For ENcryption we use a maximum of 100 bytes of plaintext and encrypt each of those byte chunks to exactly 128 byte long ciphertext.
For DEcryption we use 128 bytes long chunks of ciphertext and decrypt each to a (maximal) 100 byte long plaintext.
Note that we do not have to use exactly 100 bytes. We could and maybe should use a slightly bigger byte range. As far as I can remember the maximum length is 116 or 117 bytes, but you can easily find that out with trial and error (You will get an IllegalBlockSizeException or similar).
One method that was used above but not stated yet is the following:

private byte[] append(byte[] prefix, byte[] suffix){
	byte[] toReturn = new byte[prefix.length + suffix.length];
	for (int i=0; i< prefix.length; i++){
		toReturn[i] = prefix[i];
	for (int i=0; i< suffix.length; i++){
		toReturn[i+prefix.length] = suffix[i];
	return toReturn;

This only appends 1 byte array to the other.
And, we’re done. With this you should have all things together to encrypt large data with RSA. Note that it will take a LOT of time to encrypt 1 mb of data with this algorithm (3 minutes and more). But the main goal was to encrypt large Strings, and a String with 1 mb is really HUGE.

Hope you enjoyed the trip! Leave comments if you like it, find bugs etc :)

Did this help? Then please consider donating.
I do not need nor want money instead buy me some music so I can have fun while writing another guide! CDs (Amazon)
Alternatively, I am also totally into books. Books (Amazon)

Why I do this

I’ve been writing source code for quite some time now and have been getting quite experienced with patterns and Java.
Recently, I’ve encountered quite a few situations where I could not find any good information on the internet or the information was spread over multiple sites.

I’ve been playing around with the idea of setting up a coding blog alot already and this very last weekend I solved a problem that finally set me off installing WordPress.
I had to implement a security layer for a REST framework that we develop for a university course. The security layer should transparently encrypt and decrypt all data that passes through it and handle key exchange.

Having done my cryptography homework I did not expect this to be a huge job. Well, turns out it cost me the whole weekend which is roughtly about 20h of work.

Switch to our mobile site