好的，我已经打包了专有的二进制格式。这基本上是几个不同栅格数据集的松散包装。不管怎样，在过去，阅读这篇文章并打开包装是一件容易的事。但现在在下一个版本中，栅格 xml 数据现在将使用 AES-256 进行加密（不是我的选择，我们也没有选择）。
现在我们基本上收到了 AES 密钥以及他们正在使用的 SALT，因此我们可以修改我们的解包程序。
注意这些不是密钥只是一个例子：
它们都是 63 字节长的 ASCII 字符：
Key: "QS;x||COdn'YQ@vs-`X\/xf}6T7Fe)[qnr^U*HkLv(yF~n~E23DwA5^#-YK|]v."
Salt: "|$-3C]IWo%g6,!K~FvL0Fy`1s&N<|1fg24Eg#{)lO=o;xXY6o%ux42AvB][j#/&"
我们基本上想使用 C++ CryptoAPI 来解密它（我也是本周这里唯一的程序员，这将在明天上线。不是我们的过错）。我四处寻找实现此功能的简单教程。不幸的是，我什至找不到一个教程，其中他们同时拥有盐和密钥。基本上我现在真正拥有的只是一个接受 BYTE 数组的小函数。连同它的长度。我该怎么做？
我花了早上的大部分时间试图了解 cryptoAPI。但进展不顺利:(
编辑
所以我问他们如何加密它。他们使用 C#，并使用 RijndaelManaged，据我所知，这并不等同于 AES。
编辑2
好吧，终于知道了到底发生了什么，他们向我们发送了信息 填充
他们正在执行以下操作：
= PKCS7。
密码模式 = CBC
密钥被定义为一组 32 字节的十六进制。
IV 也被定义为一组 32 个十六进制字节。
当我要求他们时，他们拿走了盐。
使用 wincrypt.h 头文件在 CryptoAPI 中设置这些东西有多难？
Okay so i have a packed a proprietary binary format. That is basically a loose packing of several different raster datasets. Anyways in the past just reading this and unpacking was an easy task. But now in the next version the raster xml data is now to be encrypted using AES-256(Not my choice nor do we have a choice).
Now we basically were sent the AES Key along with the SALT they are using so we can modify our unpackager.
NOTE THESE ARE NOT THE KEYS JUST AN EXAMPLE:
They are each 63 byte long ASCII characters:
Key: "QS;x||COdn'YQ@vs-`X\/xf}6T7Fe)[qnr^U*HkLv(yF~n~E23DwA5^#-YK|]v."
Salt: "|$-3C]IWo%g6,!K~FvL0Fy`1s&N<|1fg24Eg#{)lO=o;xXY6o%ux42AvB][j#/&"
We basically want to use the C++ CryptoAPI to decrypt this(I also am the only programmer here this week, and this is going live tomorrow. Not our fault). I've looked around for a simple tutorial of implementing this. Unfortunately i cannot even find a tutorial where they have both the salt and key separately. Basically all i have really right now is a small function that takes in an array of BYTE. Along with its length. How can i do this?
I've spent most of the morning trying to make heads/tails of the cryptoAPI. But its not going well period :(
EDIT
So i asked for how they encrypt it. They use C#, and use RijndaelManaged, which from my knowledge is not equivalent to AES.
EDIT2
Okay finally got exactly what was going on, and they sent us the wrong keys.
They are doing the following:
Padding = PKCS7
CipherMode = CBC
The Key is defined as a set of 32 Bytes in hex.
The IV is defined as a set of 32 bytes in hex too.
They took away the salt when i asked them.
How hard is it to set these things in CryptoAPI using the wincrypt.h header file.?
发布评论
评论（2）
AES-256 使用 256 位密钥。理想情况下，系统中的每个键应该具有相同的可能性。 63 字节字符串将为 504 位。您首先需要弄清楚63个字符的字符串需要如何转换为256位（您给出的示例不是base64编码的）。其次，“盐”并不是 AES 的固有部分。您可能指的是密码块链接模式下的初始化向量 (IV)，也可能指的是以某种方式更新密钥。
如果我猜的话，我假设“SALT”指的是 IV，特别是 CBC 模式。
使用 CAPI 函数时您需要了解所有这些（例如
如果所有这些听起来令人困惑，那么最好更改您的设计，这样您就不必担心所有这些都正确。加密很难。一个错误的步骤可能会使所有安全措施失效。考虑查看此评论< /a> 在我的AES 简笔画指南。
更新：您可以看看这个作为一个粗略的开始 C++ CAPI 点。您需要一个 64 个字符的十六进制字符串才能获得 256 位（256 位/（4 位/字符）== 64 个字符）。您可以自己将字符转换为位。
我必须再次提醒大家，快速而随意地使用 IV 和按键可能会带来灾难性的后果。我深入研究了 AES/Rijndael 的数学和门级别，甚至编写了自己的实现。然而，在我的生产代码中，如果可能的话，我会坚持使用经过充分测试的 TLS 实现来处理传输中的数据。即使对于静态数据，最好使用 更高级别的库。
AES-256 uses 256 bit keys. Ideally, each key in your system should be equally likely. A 63 byte string would be 504 bits. You first need to figure out how the string of 63 characters needs to be converted to 256 bits (The sample ones you gave are not base64 encoded). Next, "salt" isn't an intrinsic part of AES. You might be referring to either an initialization vector (IV) in Cipher-Block-Chaining mode or you could be referring to somehow updating the key.
If I were to guess, I'm assuming that by "SALT" you mean IV and specifically CBC mode.
You will need to know all of this when using CAPI functions (e.g. decrypt).
If all of this sounds confusing, then it might be best to change your design so that you don't have to worry about getting all of this right. Crypto is hard. One bad step could invalidate all the security. Consider looking at this comment on my Stick Figure Guide to AES.
UPDATE: You can look at this for a rough starting point for C++ CAPI. You'll need a 64 character hex string to get 256 bits ( 256 bits / (4 bits / char) == 64 chars). You can convert the chars to bits yourself.
Again, I must caution that playing fast and loose with IV's and keys can have disastrous consequences. I've studied AES/Rijndael in depth down to the math and gate level and have even written my own implementation. However, in my production code, I stick to using a well-tested TLS implementation if at all possible for data in transit. Even for data at rest, it'd be better to use a higher level library.
Rijndael 是 AES 的算法名称
Rijndael is the algorithm name for AES