AES 128 DOT NET和Java兼容性

我们一直在尝试一种方案的原型,该方案在两个系统之间加密解密数据：一个在.NET中,另一个在Java中.我们将使用简单的128位AES加密.

我面临的问题微不足道,但是我找不到合适的解决方案.也许我对AES或加密的理解总体上还不多.

假设我们有一个预定义的密钥,由以下十六进制字符串表示：“ 9c361fec3ac1ebe7b540487c9c25e24e”.
这是一个16字节的密钥.
Java中的加密部分是

  final byte[] rawKey = hexStringToByteArray("9c361fec3ac1ebe7b540487c9c25e24e");
  final SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES");
  // Instantiate the cipher
  final Cipher cipher = Cipher.getInstance("AES");
  cipher.init(Cipher.ENCRYPT_MODE, skeySpec);

  final byte[] encrypted = cipher.doFinal(plainText.getBytes());

‘hexStringToByteArray’函数将十六进制字符串转换为字节数组.问题是在Java中,字节是有符号的.因此,值9C是-100而不是156(就像在.NET中一样).

在Java中变成：-100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78

但是在.NET中,这是：156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78

题：
鉴于密钥本身的表示形式有所不同,是否会影响加密过程本身？
这是没有CBC和PADDING的简单加密.

编辑：更新代码以使其看起来格式化.

解决方法:

我认为您根本没有问题.在两个平台上,您都有完全相同的数据.一个版本将其显示为带符号的数据,另一个版本将其显示为无符号的……但是位本身是相同的.

使用这些密钥进行加密时,我完全不会有任何问题.

标签：aes,cryptography,java,net
来源： https://codeday.me/bug/20191209/2095366.html