AES 128 DOT NET 和 Java 兼容性

发布于 2024-10-04 04:36:08 字数 1001 浏览 0 评论 0原文

我们一直在尝试一种方案的原型,在该方案中我们在两个系统之间加密解密数据:一个在 .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 的简单加密。

编辑:更新了代码以使其看起来格式化。

We have been trying a prototype of a scheme where we encrypt decrypt data between two systems: One in .NET and the other in Java. We were going to use simple 128 bit AES Encryption.

The problem I am facing is trivial, but I cannot find a proper solution. Maybe my understanding of AES or Encryption in general is less.

Assuming we have a predefined key, represented by the following hex string: "9c361fec3ac1ebe7b540487c9c25e24e".
This is a 16-byte key.
The encryption part in Java would be

  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());

The 'hexStringToByteArray' function converts the hex string to a byte array. The problem is that in java, bytes are signed. So the value 9C is -100 and not 156 (as it would be in .NET).

In Java this becomes: -100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78

In .NET however, this is: 156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78

Question:
Given that the representation of the keys itself differs, would it affect the encryption process itself?
This is simple encryption without CBC and PADDING.

Edit: Updated the code to look formatted.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

满地尘埃落定 2024-10-11 04:36:08

我不认为你有任何问题。您在两个平台上获得了完全相同的数据。一个版本将其显示为带符号的数据,另一种版本显示为无符号的......但位本身是相同的。

我不认为使用这些密钥进行加密不会出现任何问题。

I don't think that you've got a problem at all. You've got exactly the same data in both platforms. One version shows it as signed data, the other as unsigned... but the bits themselves are the same.

I wouldn't expect there to be any problem at all in using these keys for cryptography.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文