Java与Golang实现AES加密结果不一致问题咨询

首先澄清一个关键误解：Go的byte是无符号类型、Java的byte是有符号类型，这一点不会导致加密结果不同。计算机底层处理字节都是二进制流，符号只是编程语言对字节值的解释方式，AES算法基于二进制字节运算，和符号无关。

真正的问题分析 #

两段代码结果不一致的根源在以下几点：

1. 填充方式差异：
   Java中Cipher.getInstance("AES")默认使用AES/ECB/PKCS5Padding模式，PKCS5Padding会自动对长度不是16字节（AES块大小）整数倍的明文进行填充。
   而Go代码直接调用aes.NewCipher().Encrypt，这是ECB模式但没有做任何填充处理，当明文长度不是16的倍数时，加密行为完全不符合Java的逻辑。
2. 明文编码可能不一致：
   Java的message.getBytes()默认使用系统平台编码（如Windows下GBK，Linux下UTF-8），Go的[]byte(plaintext)默认是UTF-8编码，编码不一致会导致明文字节流本身就不同。
3. 错误处理缺失：
   Go代码中hex.DecodeString(secretKey)没有处理解码错误，可能导致无效密钥被传入加密函数，引发异常或错误结果。

修正后的Golang代码 #

下面是完全匹配Java逻辑的Go实现，包含PKCS5填充、统一UTF-8编码、正确的错误处理：

package main

import (
	"crypto/aes"
	"encoding/hex"
	"fmt"
)

// PKCS5Padding 实现PKCS5填充，适配AES块大小（16字节）
func PKCS5Padding(src []byte, blockSize int) []byte {
	padding := blockSize - len(src)%blockSize
	padText := make([]byte, padding)
	for i := range padText {
		padText[i] = byte(padding)
	}
	return append(src, padText...)
}

func EncryptAES(secretKey string, plaintext string) (string, error) {
	// 解码十六进制密钥，处理错误
	key, err := hex.DecodeString(secretKey)
	if err != nil {
		return "", fmt.Errorf("密钥解码失败: %v", err)
	}

	// 创建AES密码器
	c, err := aes.NewCipher(key)
	if err != nil {
		return "", fmt.Errorf("创建AES密码器失败: %v", err)
	}

	// 统一使用UTF-8编码，匹配Java显式指定UTF-8的场景（建议Java代码也显式指定编码）
	plainBytes := []byte(plaintext)
	// 对明文进行PKCS5填充
	paddedPlain := PKCS5Padding(plainBytes, aes.BlockSize)

	// 加密输出，长度等于填充后的明文长度
	out := make([]byte, len(paddedPlain))
	// ECB模式需要分块加密
	for bs, be := 0, aes.BlockSize; bs < len(paddedPlain); bs, be = bs+aes.BlockSize, be+aes.BlockSize {
		c.Encrypt(out[bs:be], paddedPlain[bs:be])
	}

	return hex.EncodeToString(out), nil
}

// CheckError 示例错误处理函数
func CheckError(err error) {
	if err != nil {
		panic(err)
	}
}

func main() {
	// 测试示例
	key := "00112233445566778899aabbccddeeff"
	plain := "test message"
	cipherText, err := EncryptAES(key, plain)
	CheckError(err)
	fmt.Println(cipherText)
}

额外建议 #

1. Java代码优化：建议显式指定加密模式、填充方式和编码，避免依赖默认值，比如：

   import java.nio.charset.StandardCharsets;
   // ...
   cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
   byte[] plainBytes = message.getBytes(StandardCharsets.UTF_8);
   

2. ECB模式风险：ECB模式是不安全的，实际项目中建议使用CBC或GCM等模式，同时配合IV（初始化向量）。

内容的提问来源于stack exchange，提问作者IshduttT