Encrypt a hex string in java

I would like to ask for any suggestions about my problem. I need to encrypt a hexadecimal string. I must not to use the built-in functions of java because it doesn't work in my server. In short, I have to hard code an algorithm or any means of encrypting the message. Anyone who could help me with this? thanks a lot!

here is the code.

public Encrypt(SecretKey key, String algorithm) {

 try {
     ecipher = Cipher.getInstance(algorithm);
     dcipher = Cipher.getInstance(algorithm);
     ecipher.init(Cipher.ENCRYPT_MODE, key);
     dcipher.init(Cipher.DECRYPT_MODE, key);
 } catch (NoSuchPaddingException e) {
     System.out.println("EXCEPTION: NoSuchPaddingException");
 } catch (NoSuchAlgorithmException e) {
     System.out.println("EXCEPTION: NoSuchAlgorithmException");
 } catch (InvalidKeyException e) {
     System.out.println("EXCEPTION: InvalidKeyException");
 }
}

public void useSecretKey(String secretString) {


 try {
     SecretKey desKey       = KeyGenerator.getInstance("DES").generateKey();
     SecretKey blowfishKey  = KeyGenerator.getInstance("Blowfish").generateKey();
  开发者_如何学JAVA   SecretKey desedeKey    = KeyGenerator.getInstance("DESede").generateKey();

     Encrypt desEncrypter = new Encrypt(desKey, desKey.getAlgorithm());
     Encrypt blowfishEncrypter = new Encrypt(blowfishKey, blowfishKey.getAlgorithm());
     Encrypt desedeEncrypter = new Encrypt(desedeKey, desedeKey.getAlgorithm());

     desEncrypted       = desEncrypter.encrypt(secretString);
     blowfishEncrypted  = blowfishEncrypter.encrypt(secretString);
     desedeEncrypted    = desedeEncrypter.encrypt(secretString);
 } catch (NoSuchAlgorithmException e) {}
}

those are the methods i used. no problem if it is run as an application but then when i put it to my server which is the glassfish server an exception occured and it says no such algorithm.

Forget about changing the code - sort out the environment.

You say it works when you run it as a command-line app - I assume you mean on your desktop. Can you do the same on the server?

What version of Java are you using in each place? Make sure that you check which version is being used in Glassfish - it may not be the same one you get when you run java -version on the command line.

As an aside, I hope your real code doesn't swallow exceptions like this.

Try RC4 algorithm, it's easy to implement.

The problem is most likely due to some kind of stuff-up with the Java bootclasspath that is in force when Glassfish is started. This often bites when an app server is launched from an IDE. For example:

> On 30-5-2005 8:00, Uwe Peuker wrote:
>
> It's probably caused by the way how/when Eclipse passes
> the -Xbootclasspath parameter to the java executable that's being
> launched.
>
> Don't know for 3.1RC1, but for older releases it depends on the setting
> "Use system default libraries" in the JRE configuration (Window ->
> Preferences -> Java -> Installed JREs -> (select JRE) -> Edit)
>
> When "Use system default libraries" is unchecked (off), Eclipse adds
> the -Xbootclasspath parameter --with all the libs in the list-- to the
> java executable. If the list doesn't include the crypto libraries, it
> results in the NoSuchAlgorithmException.
> Otherwise, when "Use system default libraries" is checked, Eclipse doesn't
> add -Xbootclasspath, so it allows the java executable to discover its own
> boot classpath including the crypto libraries.
> --
> Regards,
>
> Roland de Ruiter
> ___ ___
> /__/ w_/ /__/
> / \ /_/ / \

EDIT : in response to the OP's comment:

(In case it is is not obvious, I am neither Roland de Ruiter or Uwe Peuker. I just found that email in a Google search, and posted it here for your information.)

Anyway, since the problem arises when you launch Glassfish from Eclipse, the first thing you should try is launching Glassfish (with your app) from the command line. If that works (as I expect it will), then the problem is clearly with Eclipse and/or the way you are using it.

Assuming that I'm right, the next thing will be to capture and examine the complete set of command line arguments that Eclipse is using when launching the JRE to run Glassfish. In particular, you need to see if Eclipse is supplying a --bootclasspath option, and what its value is.

Doing your own implementation of some cryptographic algorithms has great pedagogical value, but it is not easy to do it right. For symmetric encryption, the usual recommendation is AES, which is described in great (and quite clear) details in FIPS-197. AES is a block cipher, i.e. it encrypts blocks of 16 bytes. To encrypt a "message" (supposedly longer than 16 bytes), you need some chaining and padding (the set of conventions which convert the message into some 16-byte blocks for processing by the AES); this is not very easy either. See this Wikipedia entry for an introduction on padding and chaining.

However, being unable to access the standard Java cryptographic implementations is suspicious. You shuold try to diagnose that first. Try listing (with some Java code) the registered providers, with code like this:

for (Provider p : Security.getProviders()) {
    System.out.printf("%s -> %s\n", p.getName(), p.getInfo());
}

then compare the output with what the documentation specifies. In particular the list of Sun providers.

(Note: we are talking about the server VM -- where your code runs -- and it may be a VM from some other vendor, e.g. IBM; the list of standard providers may vary.)