Encrypting/decrypting using RC2

RC2 stands for Rivest’s Code 2. More information can be found on the RSA Security site.

Main.java:

import javax.crypto.spec.*;
import java.security.*;
import javax.crypto.*;
 
public class Main
{
   public static void main(String []args) throws Exception {
      String toEncrypt = "The shorter you live, the longer you're dead!";
 
      System.out.println("Encrypting...");
      byte[] encrypted = encrypt(toEncrypt, "password");
 
      System.out.println("Decrypting...");
      String decrypted = decrypt(encrypted, "password");
    
      System.out.println("Decrypted text: " + decrypted);
   } 
 
   public static byte[] encrypt(String toEncrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance("RC2");
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // create an instance of cipher
      Cipher cipher = Cipher.getInstance("RC2");
 
      // initialize the cipher with the key
      cipher.init(Cipher.ENCRYPT_MODE, sk);
 
      // enctypt!
      byte[] encrypted = cipher.doFinal(toEncrypt.getBytes());
 
      return encrypted;
   }
 
   public static String decrypt(byte[] toDecrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance("RC2");
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // do the decryption with that key
      Cipher cipher = Cipher.getInstance("RC2");
      cipher.init(Cipher.DECRYPT_MODE, sk);
      byte[] decrypted = cipher.doFinal(toDecrypt);
 
      return new String(decrypted);
   }
}

(tested with the BouncyCastle JCE provider, http://www.bouncycastle.org)

Controlling permissions with a JApplet

It is important that you have installed the JRE1.3 on your machine, that includes the Java 1.3 plug-in.

An JApplet runs by default in a security sandbox, an environment where it has no permission to do anything that might harm the client’s machine.

Consider the following applet.

WriteFile.java:

import javax.swing.*;
import java.awt.*;
import java.io.*;
 
public class WriteFile extends JApplet {
   public void paint(Graphics g) {
      String filename = "/tmp/esusfoo";
      if (System.getProperty("os.name").indexOf("Windows") != -1) {
         filename = "C:\esusfoo";
      }
 
      try {
         BufferedWriter bw = new BufferedWriter(new FileWriter(filename));
         bw.write("The sun is green and the grass shines.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename + " created!", 10, 10);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 10);
      }
   }
}

WriteFile.html (generated with Sun’s HTMLConverter tool):

<html>
<body>
 
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.0 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">

<PARAM NAME = CODE VALUE = WriteFile >
 
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3" java_CODE = WriteFile 
WIDTH = 700 HEIGHT = 100   
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>
 
</NOEMBED></EMBED>
</OBJECT>
 
<!--
<APPLET  CODE = WriteFile WIDTH = 700 HEIGHT = 100 >
 
 
</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->
 
 
</body>
</html>

When you run this JApplet, you’ll get a security exception.
Check it out for yourself at http://www.esus.com/applets/WriteFile.html.

So what do we need to do to make this work?

You will have to explicitely give access to that applet to use resources it is normally not permitted to. To do so, one requirement is to sign our applet. The following procedure shows you how to sign an applet. You will need to have a certificate, either one you create yourself (a self-signed applet) or one that you have bought from a certificate authority like VeriSign or Thawte. For now, I’ll create one myself.

Create a certificate with keytool (JDK tool introduced in JDK1.2.2):

C:certificateapplet> keytool -genkey -alias esustest -keyalg rsa
Enter keystore password:  esuspass
What is your first and last name?
  [Unknown]:  Joris Van den Bogaert
What is the name of your organizational unit?
  [Unknown]:  ESUS Team
What is the name of your organization?
  [Unknown]:  ESUS, Inc.
What is the name of your City or Locality?
  [Unknown]:  Meerbeek
What is the name of your State or Province?
  [Unknown]:
What is the two-letter country code for this unit?
  [Unknown]:  BE
Is <CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=Unkno
wn, C=BE> correct?
  [no]:  yes

Enter key password for <esustest>
        (RETURN if same as keystore password):

C:certificateapplet>

(Note: if you haven’t used keytool before, just make up a password) Here we have created a RSA key with the name esustest. Now look in your home directory, a file should have been created called .keystore:

C:certificateapplet> dir c:windows.key*

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:WINDOWS

KEYSTO~1             1,382  07-21-01  1:28a .keystore
         1 file(s)          1,382 bytes
         0 dir(s)     164,356,096 bytes free

To see that the key has been added to the store:

C:certificateapplet> keytool -list
Enter keystore password:  esuspass

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry:

esustest, Sat Jul 21 01:28:48 CEST 2001, keyEntry,
Certificate fingerprint (MD5): 88:09:3D:97:3A:7B:91:AD:4B:01:B8:3E:40:B8:C6:2A

Now let’s create a JAR file from our applet:

C:certificateapplet>jar cvf WriteFile.jar WriteFile.class
added manifest
adding: WriteFile.class(in = 1250) (out= 732)(deflated 41%)

The jar has been created:

C:certificateapplet> dir *.jar

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

WRITEF~1 JAR         1,196  07-21-01  1:38a WriteFile.jar
         1 file(s)          1,196 bytes
         0 dir(s)     164,347,904 bytes free

Now we can sign that JAR file with our generated keypair as follows:

C:certificateapplet> jarsigner WriteFile.jar esustest
Enter Passphrase for keystore: esuspass

C:certificateapplet> dir *.jar

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

WRITEF~1 JAR         2,348  07-21-01  1:38a WriteFile.jar
         1 file(s)          2,332 bytes
         0 dir(s)     164,347,904 bytes free

Notice the size of our original JAR and the new digitally signed JAR! We can verify the JAR as follows:


C:certificateapplet>jarsigner -verify -certs -verbose WriteFile.jar

         136 Sat Jul 21 05:22:54 CEST 2001 META-INF/MANIFEST.MF
         189 Sat Jul 21 05:22:56 CEST 2001 META-INF/ESUSTEST.SF
         980 Sat Jul 21 05:22:56 CEST 2001 META-INF/ESUSTEST.RSA
           0 Sat Jul 21 05:22:16 CEST 2001 META-INF/
smk     1213 Sat Jul 21 05:21:10 CEST 2001 WriteFile.class

      X.509, CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek,
 ST=Unknown, C=BE (esustest)


  s = signature was verified
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Notice the files that have been added to the JAR file:ESUSTEST.SF and ESUSTEST.RSA. SF stands for Signature File and it includes the filename (WriteFile.class), the name of the algorithm used (RSA) and the digest value. Test it out for yourself:

C:certificateapplet>jar -xf WriteFile.jar META-INF/ESUSTEST.SF

C:certificateapplet>dir

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateapplet

.              <DIR>        07-21-01 12:32a .
..             <DIR>        07-21-01 12:32a ..
WRITEF~1 JAV           728  07-21-01  1:14a WriteFile.java
WRITEF~1 CLA         1,250  07-21-01  1:14a WriteFile.class
WRITEF~1 HTM            95  07-21-01 12:47a WriteFile.html
WRITEF~1 JAR         2,348  07-21-01  1:38a WriteFile.jar
META-INF       <DIR>        07-21-01  1:45a META-INF
         4 file(s)          4,405 bytes
         3 dir(s)     164,265,984 bytes free

C:certificateapplet>cd meta-inf

C:certificateappletMETA-INF>dir

 Volume in drive C has no label
 Volume Serial Number is 1380-0FE3
 Directory of C:certificateappletMETA-INF

.              <DIR>        07-21-01  1:45a .
..             <DIR>        07-21-01  1:45a ..
ESUSTEST SF            189  07-21-01  1:45a ESUSTEST.SF
         1 file(s)            189 bytes
         2 dir(s)     164,265,984 bytes free

C:certificateappletMETA-INF> type esustest.sf
Signature-Version: 1.0
SHA1-Digest-Manifest: Zy9znt1bwLpXeGV+pr+rkaHU4Rw=
Created-By: 1.2.2 (Sun Microsystems Inc.)

Name: WriteFile.class
SHA1-Digest: JFrqA7g/ZadrRHkJmXgsCTwZRSo=

The other file that has been added to the JAR is ESUSTEST.RSA. This is the Signature Block File It contains the certificate or certificate chain.

Now we’re ready to deploy our signed applet and see if that changed the situation. Let’s first modify our HTML file so that it uses the JAR file instead of the class file.

WriteFile2.html:

<html>
<body>
This file will create a file on your drive called esusfoo.  
Under Windows it will be located in C:, under unix it will be located in /tmp.  
If you do not want this to happen, click DENY when your browser asks you 
for additional permissions.
<br><br><br><br>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.3 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "WriteFile.class" >
<PARAM NAME = ARCHIVE VALUE = "WriteFile.jar" >

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"  CODE = "WriteFile.class" 
ARCHIVE = "WriteFile.jar" WIDTH = 700 HEIGHT = 100  scriptable=false 
pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>

</NOEMBED></EMBED>
</OBJECT>

<!--
<APPLET CODE = "WriteFile.class" ARCHIVE = "WriteFile.jar" WIDTH = 700 HEIGHT = 100>


</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->


</body>
</html>

Upload the files to your webserver and try it out! You can also try it out here:
http://www.esus.com/applets/WriteFile2.html.

With both Netscape and IE, you’ll get the following window:




Hmm, it doesn’t really create a file, does it? Well, earlier version of the plug-in (JDK1.2.2) would actually ask you if you want to grant extra permissions. But from the 1.3 plugin onwards, self-signed applets (like our WriteFile.jar) will need extra work! If you would have signed your applet with a certificate you bought from a recognized standard root CA, like VeriSign or Thawte, the browser would ask you if you want to grant additional permissions. Check out http://java.sun.com/products/plugin/1.3/docs/nsobjsigning.html!

Just like anyone else, I don’t have no money :) So for the time being, I won’t buy such a certificated from a trusted CA. But I’ll show you a way to have your applet run anyway (useful for testing purposes). It is important to realize that in order to do so, you must have access to the client’s machine(s) onto which you want to deploy your applet.

What happens when you download a signed applet is this: the browser downloads the JAR file and checks whether it is signed. If it is, it will check the security policy configuration file whether the “usePolicy” RuntimePermission is set. There are two policy files, a system-wide one, (JRE_HOME/lib/security/java.policy) and a user specific one (USER_HOME/.java.policy). In my case, my system-wide one is at C:Program FilesJavaSoftJRE1.3.1libsecurity and my user one is at C:Windows.java.policy. When the plug-in starts, it will concatenate both of them together and use them as a security policy for the rest of the session. If the usePolicy permission is set, security is controlled based on the permissions that are set in the policy files, even if you have an RSA signed applet signed by a trusted authority that wants full control over your client’s machine. This allows you to have finer-grained security control over what your signed applets are able to do.

Let’s change our policy file to grant the permission to write to the local file c:esusfoo. Add the following lines of code to your .java.policy file:

grant {
   permission java.io.FilePermission "C:${/}esusfoo", "write";
};

and test out http://www.esus.com/applets/WriteFile2.html again.

You get the following error:



Click OK, the file will be created anyway, since you granted that permission explicitely in your policy file.

To get rid of that annoying error, define the extra permission “usePolicy” in your policy file:

grant {
   permission java.lang.RuntimePermission "usePolicy";
   permission java.io.FilePermission "C:${/}esusfoo", "write";
};

Try out the applet again! No errors!

Let’s modify the applet a bit so that it also tries to write to a file c:esusfoo2. The new applet look like this.

WriteTwoFiles.java:

import javax.swing.*;
import java.awt.*;
import java.io.*;
 
public class WriteTwoFiles extends JApplet {
   public void paint(Graphics g) {
      String filename1 = "/tmp/esusfoo";
      String filename2 = "/tmp/esusfoo2";
      if (System.getProperty("os.name").indexOf("Windows") != -1) {
         filename1 = "C:\esusfoo";
         filename2 = "C:\esusfoo2";
      }
 
      BufferedWriter bw;
      try {
         bw = new BufferedWriter(new FileWriter(filename1));
         bw.write("The sun is green and the grass shines.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename1 + " created!", 10, 10);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 10);
      }
 
      try { 
         bw = new BufferedWriter(new FileWriter(filename2));
         bw.write("The sun shines and the grass is green.n");
         bw.flush();
         bw.close();
 
         g.drawString("File " + filename2 + " created!", 10, 50);
      }
      catch (Exception e) {
         g.drawString(""+e, 10, 50);
      }
   }
}

Sign the jar file as described above:

C:certificateapplet> jar cvf WriteTwoFiles.jar WriteTwoFiles.class
added manifest
adding: WriteTwoFiles.class(in = 1458) (out= 822)(deflated 43%)

C:certificateapplet> jarsigner WriteTwoFiles.jar esustest
Enter Passphrase for keystore: esuspass

WriteTwoFiles.html:

<html>
<body>
<br>
<!--"CONVERTED_APPLET"-->
<!-- CONVERTER VERSION 1.3 -->
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 700 HEIGHT = 100  
codebase="http://java.sun.com/products/plugin/1.3/jinstall-13-win32.cab#Version=1,3,0,0">
<PARAM NAME = CODE VALUE = "WriteTwoFiles.class" >
<PARAM NAME = ARCHIVE VALUE = "WriteTwoFiles.jar" >

<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
<PARAM NAME="scriptable" VALUE="false">
<COMMENT>
<EMBED type="application/x-java-applet;version=1.3"  
CODE = "WriteTwoFiles.class" ARCHIVE = "WriteTwoFiles.jar" WIDTH = 700 HEIGHT = 100  
scriptable=false pluginspage="http://java.sun.com/products/plugin/1.3/plugin-install.html">
<NOEMBED></COMMENT>

</NOEMBED></EMBED>
</OBJECT>

<!--
<APPLET CODE = "WriteTwoFiles.class" ARCHIVE = "WriteTwoFiles.jar" WIDTH = 700 HEIGHT = 100>


</APPLET>
-->
<!--"END_CONVERTED_APPLET"-->


</body>
</html>

If you run this signed applet (http://www.esus.com/applets/WriteTwoFiles.html), using the same modified policy file, esusfoo was successfully accessed but, a AccessControlException is thrown in accessing esusfoo2, as expected.

One more problem: the extra permissions to write to esusfoo and esusfoo2 are granted to all applets. You can fine-tune your policy configuration file with signedBy and/or codeBase. With signedBy, you can specify the keystore entry that contains the public key so that verification of the signed JAR file is possible. The runtime system then verifies the association of the private key with which the JAR file was signed with the public key of the specified entry in the keystore. codeBase specifies that the permissions in this grant entry are only applicable to signed applets coming from a particular code source.

Because we’re using a self-signed applet, we need to import our certificate in the keystore of the plug-in. The following steps show you how to:

  1. export the certificate to a file:
    C:certificateapplet> keytool -export -alias esustest -file esustest.cer
    Enter keystore password:  esuspass
    Certificate stored in file <esustest.cer>
    
  2. copy esustest.cer to the directory that contains the file cacerts:
    C:certificateapplet> copy esustest.cer "c:program filesjavasoftjre1.3.1libsecurity
            1 file(s) copied
    
  3. make a backup of cacerts:
    C:Program FilesJavaSoftJRE1.3.1libsecurity>copy cacerts cacerts.bak
            1 file(s) copied
    
  4. import the certificate into the cacerts keystore:
    C:Program FilesJavaSoftJRE1.3.1libsecurity>keytool -import -alias esustest
     -keystore cacerts -file esustest.cer
    Enter keystore password:  changeit
    Owner: CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=Un
    known, C=BE
    Issuer: CN=Joris Van den Bogaert, OU=ESUS Team, O="ESUS, Inc.", L=Meerbeek, ST=U
    nknown, C=BE
    Serial number: 3b58beaa
    Valid from: Sat Jul 21 01:28:42 CEST 2001 until: Fri Oct 19 01:28:42 CEST 2001
    Certificate fingerprints:
             MD5:  88:09:3D:97:3A:7B:91:AD:4B:01:B8:3E:40:B8:C6:2A
             SHA1: 6A:A1:0E:19:45:91:07:97:B0:75:BE:BB:79:91:2A:1A:27:F2:36:93
    Trust this certificate? [no]:  yes
    Certificate was added to keystore
    

    (Note: the initial password for the cacerts file is changeit as specified in the documentation)

Our self-signed certificate is now added to our database.

Run WriteTwoFiles again. Notice that now you’ll get the following dialog box:




This dialog box would also show up if your applet was signed by a certificate assigned by a VeriSign or Thawte type trusted CA.

Now change to policy file for more fine-grained control:

grant signedBy "esustest", codeBase "http://www.esus.com/applets/WriteTwoFiles.jar" {
   permission java.lang.RuntimePermission "usePolicy";
   permission java.io.FilePermission "C:${/}esusfoo", "write";
   permission java.io.FilePermission "C:${/}esusfoo2", "write";
};

Rolling your own SecurityManager

If you look in the source code for FileOutputStream, you’ll notice that, before a file is created and written to, a check is performed to see whether it is allowed to do so.

java.io.FileOutputStream.java:

    public FileOutputStream(String name, boolean append)
        throws FileNotFoundException
    {
	SecurityManager security = System.getSecurityManager();
	if (security != null) {
	    security.checkWrite(name);
	}
      . . .

If no SecurityManager is installed, System.getSecurityManager will return null and no security checks will be performed. We can see that happening by just creating an application that writes to a file.

Main.java:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

Running this code with java Main will write the file testfile.txt. If you run this code with java -Djava.security.manager Main, notice that an exception is thrown:

 Exception in thread "main" java.security.AccessControlException: access denied (
java.io.FilePermission testfile.txt write)
        at java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:195)
        at java.security.AccessController.checkPermission(AccessController.java:
403)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
        at java.lang.SecurityManager.checkWrite(SecurityManager.java:958)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:96)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:62)
        at Main.main(Main.java:5)

We could write our own SecurityManager that allows to write to testfile.txt and restricts everything else to the security sandbox.

MySecurityManager.java:

import java.io.*;
 
public class MySecurityManager extends SecurityManager {
   public void checkWrite(String file) {
      if (!file.equals("testfile.txt")) {
         throw new SecurityException("Only allowed to write to file testfile.txt.");
      }
   }
}

Now we can use our new security manager by either specifying it at command line:

C:> java -Djava.security.manager=MySecurityManager Main
testfile.txt successfully written!

or by doing so programmatically:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      System.setSecurityManager(new MySecurityManager()); 
 
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

Running:

C:> java Main
testfile.txt successfully written!

A custom security manager can be useful in JDK1.1 applications. However, it becomes a real pain (lots of programming) when you want to specify security restrictions based on who is running the code or where the code is coming from.

From JDK1.2, you can use policy files to customize the security manager in a fine-grained fashion. Let’s use the original program:
Main.java:

import java.io.*;
 
public class Main {
   public static void main(String []args) throws Exception {
      FileOutputStream fos = new FileOutputStream("testfile.txt");
      fos.write("hey".getBytes());
      fos.close();
      System.out.println("testfile.txt successfully written!");
   }
}

and write a policy file that allows writing to only the file testfile.txt:
mypolicy.txt

grant {
   permission java.io.FilePermission "testfile.txt", "write";
};

Run the code and specify the policy file to be used at runtime:

C:> java -Djava.security.policy=mypolicy.txt -Djava.security.manager Main
testfile.txt successfully written!

Install the free Bouncy Castle JCE Provider

Bouncy Castle is a free provider for JCE. These following steps will explain how to add this security provider.

  1. Download the latest release for your JDK version at http://www.bouncycastle.org/latest_releases.html
  2. Extract the zip file in your home directory
  3. BouncyCastle doens’t come with a JAR file. In order to add it to the bootclasspath, create one:
         c:jce-jdk12-107classes> jar cvf bouncycastle.jar *
         c:jce-jdk12-107classes> copy bouncycastle.jar c:jdk1.2.2jrelibext
    
  4. Go to your JAVA_HOME/jre/lib/security directory and edit the file java.security. Look at the configuration, in my case it says something like:
       security.provider.1=sun.security.provider.Sun
       security.provider.2=com.sun.crypto.provider.SunJCE
    

    Add the line security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider

  5. Run one of the examples to see if it is working (eg. How do I crypt/decrypt a message with the Blowfish algorithm?)

Update:

This information is outdated. Now, you can download JAR versions for your JDK version.

For 1.3.1, I downloaded jce-jdk13-118.jar and bcprov-jdk13-118.jar and added them to my classpath (you can also put them in jdk1.3.1/jre/lib/ext and NOT add them to your classpath).

You can add a static provider to jdk1.3.1/jre/lib/security/java.security as described above or you can do this programmatically in your code:

...
   java.security.Provider provider = new org.bouncycastle.jce.provider.BouncyCastleProvider();
   Security.addProvider(provider);

Encrypting/decrypting using RC4

RC4 (Ron’s Code) is a symmetric key encryption algorithm. Developed in 1987 by Ronald Rivest, it is used in SSL and many applications such as Lotus Notes and Oracle Secure SQL.

RC4 is a stream cipher, meaning that it encrypts one byte at a time. With RC4, the key is variable, from 1 to 2048 bits. RC4 is about 10 times as fast as DES. The algorithm is small and simple to implement. Here’s an unreadable version of it written in Perl.

Main.java:

import javax.crypto.spec.*;
import java.security.*;
import javax.crypto.*;
 
public class Main
{
   private static String algorithm = "RC4";
 
   public static void main(String []args) throws Exception {
      String toEncrypt = "The shorter you live, the longer you're dead!";
 
      System.out.println("Encrypting...");
      byte[] encrypted = encrypt(toEncrypt, "password");
 
      System.out.println("Decrypting...");
      String decrypted = decrypt(encrypted, "password");
    
      System.out.println("Decrypted text: " + decrypted);
   } 
 
   public static byte[] encrypt(String toEncrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // create an instance of cipher
      Cipher cipher = Cipher.getInstance(algorithm);
 
      // initialize the cipher with the key
      cipher.init(Cipher.ENCRYPT_MODE, sk);
 
      // enctypt!
      byte[] encrypted = cipher.doFinal(toEncrypt.getBytes());
 
      return encrypted;
   }
 
   public static String decrypt(byte[] toDecrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // do the decryption with that key
      Cipher cipher = Cipher.getInstance(algorithm);
      cipher.init(Cipher.DECRYPT_MODE, sk);
      byte[] decrypted = cipher.doFinal(toDecrypt);
 
      return new String(decrypted);
   }
}

Getting the current NT/2000/XP user using JAAS

Note: if you are using a JDK less than 1.4, make sure you have downloaded the JAAS class libraries and the sample authentication module for Windows at http://java.sun.com/products/jaas/index-10.html. Put jaas.jar and jaasmod.jar in your classpath.

Main.java:

import com.sun.security.auth.module.NTSystem;
 
public class Main {
   public static void main(String []args) {
      NTSystem ntSystem = new NTSystem();
      System.out.println(ntSystem.getName());
   }
}

outputs on my machine:

C:myjaastest>java -Djava.library.path=c:javatoolsjaasmod1_0lib Main
esus

To get other NT properties:

import com.sun.security.auth.module.NTSystem;
import java.util.Arrays;

public class Main {
   public static void main(String []args) {
      NTSystem ntSystem = new NTSystem();
      System.out.println(ntSystem.getName());
      System.out.println(ntSystem.getDomain());
      System.out.println(ntSystem.getDomainSID());
      System.out.println(Arrays.asList((Object[])ntSystem.getGroupIDs()));
      System.out.println(ntSystem.getImpersonationToken());
      System.out.println(ntSystem.getPrimaryGroupID());
      System.out.println(ntSystem.getUserSID());
   }
}

outputs:

C:myjaastest>java -Djava.library.path=c:javatoolsjaasmod1_0lib Main
esus
WORKGROUP

[S-1-5-21-3978503659-2915903831-1203752577-513, S-1-1-0, S
-1-5-32-544, S-1-5-32-545, S-1-5-5-0-51662, S-1-2-0, S-1-5
-4, S-1-5-11]
1252
S-1-5-21-3978503659-2915903831-1203752577-513
S-1-5-21-3978503659-2915903831-1203752577-1007

What is PKCS#5 padding?

Ciphers process data in blocks, for example 8 byte blocks. If the length of the data that you want to encrypt is not evenly divisible by the blocksize that your encryption algorithm uses, the data needs to be padded. PKCS#5 is one way of padding. It appends to every message a block of data varying from 1 to 8 bytes where each bytes contain the number of bytes that are padded.

For instance, if the length of the data is 10, then 6 bytes need to be padded. The last block of 8 bytes will look like this:

 +---+---+---+---+---+---+---+---+
 | D | D | 6 | 6 | 6 | 6 | 6 | 6 |
 +---+---+---+---+---+---+---+---+

If the length of your data happens to be evenly divisible by 8, an extra 8 bytes will be added looking like this:

 +---+---+---+---+---+---+---+---+
 | 8 | 8 | 8 | 8 | 8 | 8 | 8 | 8 |
 +---+---+---+---+---+---+---+---+

This is because PKCS5Padding always assumes there is a pad.

Encrypting/decrypting using RC5

RC5 (Ron’s Code) is a block cipher, blocks of data are encrypted. Block size, key size and security level can be customized. In his paper, Ronald Rivest talks about a “variable number of rounds” allowing the user to make a tradeoff between higher security and higher speed, and a “variable length cryptographic key”. For more information, consult this cryptobytes edition (PDF).

Main.java:

import javax.crypto.spec.*;
import java.security.*;
import javax.crypto.*;
 
public class Main
{
   private static String algorithm = "RC5";
 
   public static void main(String []args) throws Exception {
      String toEncrypt = "The shorter you live, the longer you're dead!";
 
      System.out.println("Encrypting...");
      byte[] encrypted = encrypt(toEncrypt, "password");
 
      System.out.println("Decrypting...");
      String decrypted = decrypt(encrypted, "password");
    
      System.out.println("Decrypted text: " + decrypted);
   } 
 
   public static byte[] encrypt(String toEncrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // create an instance of cipher
      Cipher cipher = Cipher.getInstance(algorithm);
 
      // initialize the cipher with the key
      cipher.init(Cipher.ENCRYPT_MODE, sk);
 
      // enctypt!
      byte[] encrypted = cipher.doFinal(toEncrypt.getBytes());
 
      return encrypted;
   }
 
   public static String decrypt(byte[] toDecrypt, String key) throws Exception {
      // create a binary key from the argument key (seed)
      SecureRandom sr = new SecureRandom(key.getBytes());
      KeyGenerator kg = KeyGenerator.getInstance(algorithm);
      kg.init(sr);
      SecretKey sk = kg.generateKey();
 
      // do the decryption with that key
      Cipher cipher = Cipher.getInstance(algorithm);
      cipher.init(Cipher.DECRYPT_MODE, sk);
      byte[] decrypted = cipher.doFinal(toDecrypt);
 
      return new String(decrypted);
   }
}

Get a private key from a keystore

This example extracts a private key from a keystore and prints it out in PEM format.

Main.java:

import sun.misc.BASE64Encoder;
import java.security.cert.Certificate;
import java.security.*;
import java.io.File;
import java.io.FileInputStream;
 
class Main {
   public static void main(String args[]) throws Exception{
      if (args.length != 3) {
         System.out.println("Extracts private key in PEM format from a JKS keystore");
         System.out.println("Usage: java Main <keystore> <alias> <passphrase>");
         System.exit(1);
      }
 
      String keystore = args[0];
      String alias = args[1];
      String password = args[2];      
 
      KeyStore ks = KeyStore.getInstance("JKS");
      char[] passphrase = password.toCharArray();
      BASE64Encoder base64Encoder = new BASE64Encoder();
 
      ks.load(new FileInputStream(keystore), passphrase);
 
      PrivateKey privateKey = getPrivateKey(ks, alias, passphrase);
 
      String sPrivateKey = base64Encoder.encode(privateKey.getEncoded());
 
      System.out.println("-----BEGIN PRIVATE KEY-----");
      System.out.println(sPrivateKey);
      System.out.println("-----END PRIVATE KEY-----");
   }
 
   public static PrivateKey getPrivateKey(KeyStore keystore, String alias, char[] password) {
      try {
         Key key = keystore.getKey(alias, password);
         if (key instanceof PrivateKey) {
            Certificate cert = keystore.getCertificate(alias);
            PublicKey publicKey = cert.getPublicKey();
 
            KeyPair kp = new KeyPair(publicKey, (PrivateKey)key);
 
            return kp.getPrivate();
         }
      } catch (UnrecoverableKeyException e) {
         e.printStackTrace();
      } catch (NoSuchAlgorithmException e) {
         e.printStackTrace();
      } catch (KeyStoreException e) {
         e.printStackTrace();
      }
 
      return null;
   }
}