Wednesday, 13 April 2011

XTEA Encryption Interoperability

Recently someone I work with had a requirement to encrypt data in the browser on the client (ActionScript) and have the data decrypted on the server (Java).  His initial approach was to use the XTEA[1][2] encryption algorithm (XTEA = eXtended TEA, where TEA = Tiny Encryption Algorithm) due to its speed and ease of implementation.  XTEA implementations were found for both Java[3][4] and ActionScript[5][6].

After some quick testing, it became clear that while both implementations would encrypt text and then allow the encrypted text to be successfully decrypted, the two implementations would not interoperate.  They generated different cipher text given the same key and plain text.  I had some time available and was interested in the topic so I took a look at the code and did a little research.

As always, the devil is in the details.  The core of the two algorithms looked basically the same, but there were some issues.  The Java package was a bare bones implementation.  You initialized a key and an operation (encrypt/decrypt) and then passed in 8 bytes of data and received back 8 bytes of processed data.  The ActionScript  class was similar, but the demo UI that I used for testing[7] wrapped the basic algorithm with additional functionality which provided a mode[8], padding, and an initialization vector.  Not being a Flex/ActionScript programmer, I was using the UI to test the ActionScript code, although my friend did set me up to allow debugging of the ActionScript code in Eclipse.  This proved invaluable as it allowed me to single step and see the state of the variables in the same manner as the Java code.

So the first challenge was to see if I could determine how to remove the mode/padding/initialization vector from the equation.  After some research I determined that if I insured that my plain text was a multiple of 8 bytes then I could specify NONE for the padding method.  Similarly, the ECB or Electronic Code Book mode encrypts each block of 8 characters using only the key without any feedback from other plain text or cipher text.  Specifying ECB essentially eliminated the mode as an issue, and since the initialization vector is not used in ECB it went away as well.

Next up was character encoding.  Since I was starting with Strings as my plain text in Java, I needed to insure that the bytes returned by getBytes() matched those being processed in the browser.  I specified the US-ASCII character set in my getBytes() call and verified that on the browser I was getting the same bytes being passed into the XTEA encrypt method on the client.  However, the encrypted results were still different on the two platforms.

I took a closer look at the code and saw some differences:

  1. The ActionScript code was performing 64 rounds while the Java code was only performing 32.  I changed the Java code to 64.

  2. The ActionScript code was initializing the 'sum' to the 'delta' value times the number of rounds for decryption.  The java code was initializing it to a constant, which as it turns out was equal to 32 * the 'delta' value.  I changed the initialization to be ROUNDS * DELTA so when ROUNDS changes the 'sum' initialization would change appropriately.

  3. The packing and unpacking of data bytes and key bytes differed between the two implementations.  In the Java version, byte 0 of the input was being placed in the low order position (bits 24 to 31 of the first 32 bit word), the second to the left of the first (bits 16 to 23), so a single-byte character stream coming in like this: A B C D E F G H would end up in the two 32 bit words like this:  D C B A   H G F E.  The ActionScript ordered them in the manner that I would expect (A B C D  E F G H).  I modified the Java code to do the same as the ActionScript for the data packing, unpacking, and the key packing.  Note that I am not sure which way is correct, I just changed the Java side because it made more sense to me, and it was easier for me.

  4. Lastly, I determined after a significant amount of effort and some dumb luck that the ActionScript implementation had a bug.  The right shifts in the code (>> ) should be unsigned right shifts (>>> ) otherwise the high order bit gets replicated instead of being replaced with a zero.  After I figured this out, I went to post an issue against the project and there was already an issue posted :o  egg on my face.

After these four changes, the cipher text from each implementation matched for the same input, and the decryption for both implementations successfully decrypted the cipher text.

The final modified ActionScript code is here[9] and the final modified Java code is here[10].  There is a license file associated with the ActionScript code, and it is here[11].

As time permits I will be looking into the following:
  • Adding mode and padding support around the Java code
  • Publishing a set of expected cipher text values given a set of input values.  There doesn't seem to be any practical way to insure that an algorithm is generating the correct results.  This appears to have resulted in various incompatible (and possibly incorrect) implementations out on the web.
  • Looking into extending the javax.crypto Service Provider Interface so XTEA can be easily integrated into any Java app using standard interfaces.
  • Look into writing a Javascript version of XTEA


[1] XTEA algorithm description
[2] TEA/XTEA Background and History
[3] Original Java XTEA implementation source code 
[4] Copy of original Java XTEA implementation source code on my server, just in case 
[5] Original ActionScript XTEA Implementation   
[6] Copy of original ActionScript XTEA implementation source code on my server, just in case  
[7] ActionScript Crypto Package Demo UI
[8] Block Cipher modes of operation and padding 
[9] Modified Java XTEA implementation source
[10] Modified ActionScript XTEA implementation source
[11] Crypto package license file

 

 

Technorati Tags:

Posted by john at 3:16 PM in Cryptography

Tuesday, 7 December 2010

Java By Value or By Reference?

HTML Source EditorWord wrap HTML Source EditorWord wrap

I have recently seen several long threads discussing the topic "Does Java pass parameters by value or by reference?".  I wanted to add my two cents here.

The short answer is as follows:

1) Java passes primitive parameters by value

2) Java passes object references by value

The sticking point is that #2 is considered by many to be the definition of passing by reference.

The long answer:

First, let me say that definition of terms is critical in this discussion.  It is easy to disagree on larger points when we don't agree on the definition of key terms.

For the purposes of this discussion I define pass by value to be creating a copy of the value to be passed and passing the copy to the formal parameter of the method.

Similarly, pass by reference is defined as passing a reference (typically called a pointer) to the value to be passed.

One other important point is that in Java we do not pass objects as parameters, we pass references.  I believe that this is the key piece of information that gets missed during discussions about this topic.

In Java, parameters only come in two flavors: primitives and references.  Java always makes a copy of the parameter and passes the copy, hence Java ALWAYS passes by value.

You can see that this is true in the code example below:

package byvalue;
import java.awt.Point;
public class Main {
    public static void main(String[] args) {
        Main main = new Main();
        main.test();
    }
    void test() {
        int i = 1;
        Point point1 = new Point(1,1);
        Point point2 = new Point(2,2);
        
        testRef(i, point1, point2);
        System.out.println("i=" + i + 
                " point1=" + point1.getX() +"," + point1.getY() + 
                " point2=" + point2.getX() +"," + point2.getY());
    }
    void testRef(int i, Point p1, Point p2) {
        i = 2;
        p1 = new Point(3,3);
        p2.setLocation(4,4);
    }
}

Output:  i=1 point1=1.0,1.0 point2=4.0,4.0

The change to the value of i and assigning a new object to p1 had no effect outside the testRef method.

However, and this is the point that the pass by reference folks hang their hat on, the location of point2 does get modified!  This is, of course, because the value passed to the method is a reference.  While the reference cannot be made to point to a different object, the object it references can be manipulated.

From a practical point of view for most engineers, what we call it matters less than understanding how it works.  What you need to know is that primitives are passed by value and references are passed by value, so changes to those parameters inside the called method have no impact outside the method.  However, the object pointed to by a passed reference is in fact the same object outside the method and any changes made to the object inside the method will be seen outside the method.

Let me know what you think.

 

Technorati Tags:

Posted by john at 7:40 PM in Java

Saturday, 27 October 2007

My Introduction to Netbeans

When my ancient JBuilder4 would not run JDK 1.4, I had to find a new IDE or pony up the $$$ for a new version of JBuilder.  I run a small consulting firm, so I get to make the decisions.  Since both Netbeans (4.0) and Eclipse (2.1?) were on the scene by that time (early 2005) I decided to give them each a test drive.  I downloaded both packages and tried them out without the benefit of reading any documentation.

 

The clear winner out of the box for a user with no experience with either IDE was Netbeans.  This does not necessarily make Netbeans a better overall choice, it was just easier to get started.  I found it easy to create projects, write code, compile and run the code.  The concepts of projects was easy to grasp and the structure of the directories was easy to understand. 

 

Eclipse, on the other hand, expected me to understand workspaces, projects, perspectives, builders, build paths, and so on, before I could get something to work.  The terminology does not match any Java terminology that I am aware of and there did not seem to be any definitions or explanations anywhere.  It was just assumed that you would know what these objects represented and why and how you would use them.  I think the Help (which was all that I read, and not much of that) was too generic, assuming that you might be using the platform for almost anything rather than for writing Java code.  Based on this narrow distinction, I chose Netbeans.

 

I have enjoyed Netbeans.  The product is being continually enhanced by the product team at netbeans.org and it has served all my needs well.  Most of the time I don’t demand too much out of my IDE.  I need to be able to easily write code and refactor, quickly run through modify, compile, test cycles, and easily access code in multiple projects at the same time.  I have written a lot of Swing and the GUI builders in 2005 were good for the initial layout.  I found that manual adjustments were always needed after the fact either through code modification or more often by adjusting (sometimes many) properties through the GUI. 

 

The debug features are quite nice and allowed me to quickly locate bugs that cropped up in my code.  I also make use of the database access features.  This allows me to connect to a variety of types of databases from within my GUI and poke around quickly and easily with a consistent interface.  My customers use a variety of databases with Oracle, Sql Server and MySql being the most frequent choices.  I like to write my apps to be as database agnostic as possible as I occasionally have a customer switch the target database during the project once they see what the production licenses will cost.

 

I also write small webapps that are pretty typical custom apps for small to mid-size businesses.  Netbeans has proven up to that task as well, integrating well with Tomcat and allowing quick turnaround with hot code replacement.  The CVS enhancements made in Netbeans 5.0 have made the CVS integration far easier to use.  The Matisse GUI Builder in 5.0 is also a winner. 

 

Netbeans has done a good job for me.  It is easy to learn to use, which is important as I bring on new developers.  That's it for now.  More on Netbeans and Eclipse is coming in future entries.

 
Posted by john at 3:52 PM in Netbeans

Saturday, 20 October 2007

Introduction

My name is John Barry and this is my blog. I decided to start this blog for two reasons. First, I would like to have a place to record the many issues and solutions that I come across on a daily basis as a Java developer that other Java developers may also encounter. The intent is that the solutions I come across may help other developers resolve their issues more quickly. Second, I would like to encourage a healthy (and respectful) exchange of opinions on a variety of Java related topics. It is clear that there are many points of view on any given topic and I know that from my position (often heads down coding) it can be difficult to even see that other points of view may exist.  I am hoping that this blog will be a vehicle to help remedy that situation.

Posted by john at 8:37 PM in Introduction
« June »
SunMonTueWedThuFriSat
    123
45678910
11121314151617
18192021222324
252627282930