在 JAVA 中,从 J2EE1.4 开始,SUN 提供了 JCE( JAVA CRYPTO ENGINE ),其中包含有 DES 算法,在 JAVA 中使用 DES 算法的代码示例如下:
import java.security.Key; import java.security.Security; import javax.crypto.Cipher; public class DESPlus { static String strDefaultKey = "initkey"; static Cipher encryptCipher = null; static Cipher decryptCipher = null; static { Security.addProvider(new com.sun.crypto.provider.SunJCE()); Key key = null; try { key = getKey(strDefaultKey.getBytes()); encryptCipher = Cipher.getInstance("DES"); encryptCipher.init(Cipher.ENCRYPT_MODE, key); decryptCipher = Cipher.getInstance("DES"); decryptCipher.init(Cipher.DECRYPT_MODE, key); }catch(Exception e){ e.printStackTrace(); } } public DESPlus(){ } public static byte[] encrypt(byte[] arrB) throws Exception { return encryptCipher.doFinal(arrB); } public static byte[] decrypt(byte[] arrB) throws Exception { return decryptCipher.doFinal(arrB); } private static Key getKey(byte[] arrBTmp) throws Exception { byte[] arrB = new byte[8]; for (int i = 0; i < arrBTmp.length && i < arrB.length; i++) { arrB[i] = arrBTmp[i]; } Key key = new javax.crypto.spec.SecretKeySpec(arrB, "DES"); return key; } }
需要注意的是,加密后的结果是字节数组,一般情况下可以使用 BASE64 进行编码,以方便存储在字符串形的数据库字段中,当然亦可以采用原始的字节流或者是十六进制编码字符串;同样需要注意的是,在上面的代码示例中,JAVA 的 DES 算法可以指定加密的模式和填充方式,如果不指定,则默认的就是 ECB 加密模式和 PKCS#5 填充方式,关于加密模式和填充方式之后将进行介绍,现在我们来看 OPENSLL 的 DES 算法,还是先给一段代码示例:
int Encrypt( unsigned char * inbuf , unsigned char * * outbuf , int inlen , unsigned char * key, unsigned char * iv ) { BIO *bio, *mbio, *cbio; unsigned char *dst; int outlen; mbio = BIO_new( BIO_s_mem( ) ); cbio = BIO_new( BIO_f_cipher( ) ); BIO_set_cipher( cbio , EVP_des_ecb( ) , key , iv , 1 ); bio = BIO_push( cbio , mbio ); BIO_write( bio , inbuf , inlen ); BIO_flush( bio ); outlen = BIO_get_mem_data( mbio , (unsigned char **) & dst ); * outbuf = ( unsigned char * ) malloc( outlen ); memcpy( * outbuf , dst , outlen ); BIO_free_all( bio ); return outlen; }
该段代码使用了 OPENSSL 库,该函数返回加密结果的长度,同时将加密的结果放置在 outbuf 中,需要注意的是,BIO_set_chiper 这一行,最后两个参数:iv 参数在 ECB 加密模式下是不起作用的,仅 CBC 模式才会使用该变量,该变量要求必须是一个八字节的数组,enc 参数,如果是 1 则表明是进行加密,如果是 0 则表明是解密,-1 则表明使用最后一次操作的方式,只需要修改最后一个参数为0,就是解密了,所以解密的代码就不再重复了;
另外补充一点,这个加密方式是最古老的 DES ,不是 3DES ,输入参数 KEY 的长度要求至少是 8 个字节,如果不够,补 '\0',例如:unsigned char key[ ] = { "key\0\0\0\0\0" },如果超过八个字节,那么后面的不使用;如果你不愿意补零,那么需要保证和 JAVA 的对应,否则不能互相加解密;
哦,还有一点,请注意在使用完后释放 outbuf 内存块,保证没有内存泄露;
下面来说一下加密模式,常见的加密模式有 ECB / CBC / CFB / OFB 四种,这也是 OPENSSL 提供的四种,加密模式的主要意义就是,加密算法是按块进行加密的,例如 DES ,是 64Bit 一个块的进行加密,就是每次加密 8 个字节,因此每次输入八个字节的明文输出八个字节密文,如果是 16 个字节,那么分成两个块依次进行加密,问题就出现在这里,如果明文是 1234567812345678,分块分别进行加密,那么加密的结果类似“C4132737962C519C C4132737962C519C”,可以看出明文的规律,这就是 ECB 加密模式,密文可以看出明文的规律;为了解决这个问题,有了其他的加密模式:CBC 加密模式(密码分组连接),CFB加密模式(密码反馈模式),OFB加密模式(输出反馈模式)CBC 是要求给一个初始化的向量,然后将每个输出与该向量作运算,并将运算的结果作为下一个加密块的初始化向量,CFB 和 OFB 则不需要提供初始化向量,直接将密码或者输出作为初始化向量进行运算;这样就避免了明文的规律出现在密文中;当然缺点是解密时需要保证密文的正确性,如果网络传输时发生了一部分错误,则后面的解密结果就可能是错误的;(ECB模式仅影响传输错误的那个块);
密码算法基本上都是分组(按快)进行加密的,如果密文长度不是刚刚好可以进行分组,怎么办?只能进行填充,填充的方法有很多中,常用的是 PKCS#7,该填充方法是将每一个补充的字节内容填充为填充的字节个数;例如明文长度是 100 , 分组的大小是32个字节,那么需要分为四组,补充28个字节,那么补充的字节全部补充为'\0x28',如果分组的大小是 8 个字节,那么 PKCS#7 的填充方式和 PKCS#5 是完全一致的;另外还有一个规定,就是如果明文刚刚好进行分组,那么需要补充一个独立的分组出来,例如 DES ,如果明文为 8 个字节,那么需要补充为 16 个字节进行运算,这样的好处是进行解密后,将解密出来的最后一个字节取出来,并将解密结果的长度减去该值,就是原来明文的长度;
更多的信息可以参考:http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation