常见DES实现陷阱

| Comments

DES要点说明

  • DES走的是分组加密,每次处理对象的是8位byte,所以对字符串加解密的时候,会涉及字符编码格式和补齐8位的问题。
  • DES的密钥是固定8位的byte的,其中前7位是加解密用的,最后一位是校验码。
  • 3DES的增强型的DES,带3个key,如果3个key一样,就是DES,也有一种变种是1、3是一样的。但都是固定8位的。
  • 3DES通常是EDE,就是先加密(k1)再解密(k2)再加密(k3)

目前,项目代码中有3个和DES实现相关的类,下面看看他们有哪些问题:

案例1

  • 从字符串到byte的转换,有指定编码格式GBK,这个是可以接受的。
  • 使用的是DESede,就是3DES的EDE加密方式,但是3个key是一样的,没有意义。
  • 加密时代码先自行进行了补齐操作(补\0),但是补齐是在字符串上操作的,不是在字节上操作,导致实际上可能没有对齐(中文情况)。
  • 调用加密API时,没有指定补齐方式,会采用默认补齐,造成重复补齐(当然也修复了上面的补齐操作)。
  • 解密指定NoPadding,和加密Padding方式不一样,造成解密结果最后会出现很多多余的字节。所以结果必须得trim一下才行。

参考代码如下:

补齐实现有误:

    public String encrypt(String in) throws Exception {
        String strIn = in;
        if (null == strIn || "".equals(strIn)) {
            return "";
        }

        int i = 0;
        i = strIn.length() % 8;

        if (0 == i) {
            for (i = 0; i < 8; i++) {
                strIn += "\0";
            }
        } else {
            while (i > 0) {
                strIn += "\0";
                i--;
            }
        }
        byte[] bytes = strIn.getBytes(CHARSET);
        byte[] enbytes = encryptCipher.doFinal(bytes);
        return byteArrToHexStr(enbytes);
    }

key是一样的,补齐方式没对应上:

    public DESedeEncrypt() {
        byte[] buffer = new byte[] {
                0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31,
                0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31, 0x31
        };

        SecretKeySpec key = new SecretKeySpec(buffer, "DESede");

        try {
            encryptCipher = Cipher.getInstance(KEY_ALGORITHM);
            encryptCipher.init(Cipher.ENCRYPT_MODE, key);
            decryptCipher = Cipher.getInstance("DESede/ECB/NoPadding");
            decryptCipher.init(Cipher.DECRYPT_MODE, key);
        } catch (NoSuchAlgorithmException e) {
            Throwables.propagate(e);
        } catch (NoSuchPaddingException e) {
            Throwables.propagate(e);
        } catch (InvalidKeyException e) {
            Throwables.propagate(e);
        }
    }

案例2

  • 从字符串到byte的转换,采用了系统默认编码,存在平台移植性问题。
  • 密钥key的长度布置8位,有多余字符(虽然只取前8位避免出错),造成混乱。

key的格式不标准,有多余字符:

    private static String strDefaultKey = "mywebsite123456%";
    private 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;
    }

案例3

  • 从字符串到byte的转换,采用了系统默认编码,存在平台移植性问题。
  • 实现不是标准的DES,或3DES,是在DES基础上定义了一套加密。
  • 根据目前key的长度,比标准3DES都要慢很多,另外没有采用JDK带的API。

key的长度不标准:

public class DesUtil {
    public static final String firstKey = "com.xxx.xxxpro";
    public static final String secondKey = "xxx_web";
    public static final String thirdKey = "xxxservice";
}

实现方式是对每个key补齐8位,再切割形成每组多个8位的key,再采用EEE的方式进行处理:

                        for (x = 0; x < firstLength; x++) {
                            tempBt = enc(tempBt, (int[]) firstKeyBt.get(x));
                        }
                        for (y = 0; y < secondLength; y++) {
                            tempBt = enc(tempBt, (int[]) secondKeyBt.get(y));
                        }
                        for (z = 0; z < thirdLength; z++) {
                            tempBt = enc(tempBt, (int[]) thirdKeyBt.get(z));
                        }

Comments