Ready reference for Web Service Types

TripleDES encryption compatibility when using Java and .NET

Note: This article shows you how to generate a SecretKey to use with a TripleDES encryption cipher. The shared-secret key can be 24 byte or even 16 bytes long.

For a quick brief of how TripleDES (3DES) works have a look here.

The most common problem related to encrypting something in Java and decrypting in .NET or vice-versa is a misunderstanding of the Keying options that are defined in the standards and those implemented by Java and .NET

A DES key is made up of 56 bits and 8 parity bits (8 bytes)

A 3DES key is made up of a bunch of 3, 8-byte DES keys i.e. a 24 bytes long

If you are going to use a 24 byte key for both Java and .NET, you're safe; then encryption will be compatible.

Java will force you to use only a 24 byte key when using TripleDES; the subtly is that .NET supports both a 16 byte as well as a 24 byte key.

Now If you generate a key from a MD5 hash of a shared secret, it will be just 16 bytes. .NET has no problem with this. It implements Keying Option 2. It will intelligently take the first 8 bytes and append it after the 16th byte - forming a 24 byte key. Java, *sigh* sadly doesn't do this. You'll have to spoon feed it like so:

public SecretKey getSecretKey(byte[] encryptionKey) {
 SecretKey secretKey = null;
 if (encryptionKey == null)
   return null;

byte[] keyValue = new byte[24]; // final 3DES key

if (encryptionKey.length == 16) {
 // Create the third key from the first 8 bytes
 System.arraycopy(encryptionKey, 0, keyValue, 0, 16);
 System.arraycopy(encryptionKey, 0, keyValue, 16, 8);

} else if (encryptionKey.length != 24) {
 throw new IllegalArgumentException("A TripleDES key should be 24 bytes long");

} else {
 keyValue = encryptionKey;
}
 DESedeKeySpec keySpec;
try {
 keySpec = new DESedeKeySpec(keyValue);
 SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DESede");
 secretKey = keyFactory.generateSecret(keySpec);
} catch (Exception e) {
 throw new RuntimeException("Error in key Generation",e);
}
 return secretKey;
}

Damn Small Linux: Install files with .dsl extension

The DamnSmallLinux live CD/USB allows you run DSL in memory. It also allows you to run apps that you download from the MyDSL repository. If you install DSL to HDD/USB then you'll want to have these apps permanently on your system. You can do this easily.
If you look carefully, the MyDSL repository, contains a lot of files (apps) with the .dsl extension.

A .dsl extension file is nothing but a compressed archive in the tar-gzip format.

All you need to do is:

1. download the .dsl file to any location (lets say /home/dsl)
2. cd /
3. tar -zxvf /home/dsl/.dsl

and you're through!

JPA and Stored Procedures

I recently stumbled upon many queries on google about how to make Stored Proc calls via JPA. Something was not right with questions like this.

Stored Procs and JPA are completely different beasts with completely different philosophies behind them. Sure you can call stored procs using JPA but thats using the wrong hammer. JPA deals with persistence of entities; Stored procs, with business logic being closest to the data.

If you have a lot of business logic in stored procs, you have the advantage of speed, security and maintainability, however, you lose portability of your business logic if you change your database. Now, in any large-scale enterprise, the database vendor is not really going to change and a database (oracle/sql server/db2) is going to be a uniform commitment across the organization. Having said that, even if you have to port the procs from one database to another, the vendor documentation will include quite comprehensive migration guides for the same. They have to :) For the record, IMHO, I normally stick with stored procs for the reasons listed above. I always have some real DBA cats working on my team that perform something called ATM (Application Transaction Modelling) on the database. Look it up (ATM). Once they are through with this you can flex your ORM muscles all you like, but in the end what you will be left with will just be UGLY. 

Been there, done that, got the T-Shirt.

HP Laptops with XP - Brightness buttons dont work - Fix

If you've got a new HP laptop and have formatted it (to probably get rid of the lousy Vista OS) 

and installed or downgraded it to XP you'll have noticed something that people all over seem to be annoyed with: 

The brightness keys Fn F7 and F8 don't work once the XP OS starts loading into memory.

HP has probably rigged this to work only with Vista. So you're stuck.. right?

Nope :)

Here's the surefire fix:

1. Just download the .NET 2.0 framework from microsoft 

2. And then hop across to HP and search for something called HP Quick Launch Buttons or do a google search for "HP Quick Launch Buttons "

3. Download it for your laptop model. Install it and reboot. 

After this you should have your laptop running XP with the Fn F7 and F8 brightness buttons working!