openssl 3.0.2带定制盐的openssl dy salted __

发布于 2025-01-26 21:45:48 字数 1048 浏览 1 评论 0 原文

我刚刚将Ubuntu系统升级到22.04，它随附OpenSSL 3.0.2。以前，我正在使用1.1.1f，看来行为已经改变，但是我不确定（1）为什么和（2）如何获得旧行为或新行为是什么，以便我可以适应它。

问题是我期望任何OPENSL加密文件以字节开头：base64中的“ salted__”或“ u2fsdgvkx1”。我正在使用它来确定文件是否已加密。

如果我使用openssl 3的随机生成的盐，则可以正常工作。

echo "foo" >secret.txt
ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -pbkdf2 -in secret.txt -a

结果：

U2FsdGVkX1+BM+juJUWhy5eqBJ3k5BrrTs/V4l0QstA=

我在1.1.1F版本中获得了类似的结果，但是它是随机的，因此是非确定性的。

但是，在我正在研究的应用程序中，我需要确定性，因此我需要提供盐。这并不是一件大事，可以让您使用 -s 来完成此操作。在1.1.1f上，我可以做到这一点：

ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -S 5555555555555555 -pbkdf2 -in secret.txt -a

U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg=

这是确定性的，因此您可以使用我所做的相同秘密并获得相同的结果。

但是在3.0.2上，我得到了相同的命令：

CQr5YjGuI7hpkdeXEk7MOA==

这也是确定性的，但是为什么有所不同？似乎没有一致的模式。

发生了什么？他们是否停止将盐准备给消息？如果需要的话，我只需要手动添加一点吗？我有什么可以让OpenSSL再次为我做的吗？行为改变的原因是什么？

原文

I have just upgraded my Ubuntu system to 22.04 which comes with OpenSSL 3.0.2. Previously I was using 1.1.1f, and it seems the behavior has changed, but I'm not sure (1) why and (2) how to get the old behavior or what the new behavior is so I can adapt to it.

The issue is that I was expecting any openssl encrypted file to start with the bytes: "Salted__" or "U2FsdGVkX1" in Base64. I'm using that to determine if the file is encrypted or not.

If I use OpenSSL 3 with randomly generated salt things work fine.

echo "foo" >secret.txt
ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -pbkdf2 -in secret.txt -a

Results in:

U2FsdGVkX1+BM+juJUWhy5eqBJ3k5BrrTs/V4l0QstA=

And I get a similar result with version 1.1.1f, but it's random so it's non deterministic.

However, in the application I'm working on, I need determinism, so I need to provide the salt. That's not a big deal openssl lets you do that with -S. On 1.1.1f I can do that and get:

ENC_PASS=chbs openssl enc -aes-256-cbc -md sha256 -pass env:ENC_PASS -e -S 5555555555555555 -pbkdf2 -in secret.txt -a

U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg=

This is deterministic, so you can use the same secret I did and get the same result.

But on 3.0.2 with the same command I get:

CQr5YjGuI7hpkdeXEk7MOA==

This is also deterministic, but why is it different? There doesn't seem to be a consistent pattern.

What happened? Did they stop prepending the salt to the message? Do I just have to manually add that bit if I want it? Is there anything I can do to get openssl to do that for me again? What was the reason for the change in behavior?

分享到QQ

分享到微博

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

发布评论

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

狼亦尘 2025-02-02 21:45:48

这不是真正的编程或开发，因此应该是偏离的，但是由于您让我看：

是的，它更改了，不是具体的3.0.2，而是所有3.0.x（来自3.0之前/之前的alpha .0至3.0.3）;参见。现在，当您使用 -s 时，它不再写入或读取由盐的____ 加上8个字节盐组成的16个字节。

没有选择来控制这一点。当然，由于OpenSSL是开源的，只要您不将其与许可证不一致，您可以根据需要分叉并修改它。

明显的base64差异完全是结果。

$ <<<U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg= openssl base64 -d |xxd
00000000: 5361 6c74 6564 5f5f 5555 5555 5555 5555  Salted__UUUUUUUU
00000010: 090a f962 31ae 23b8 6991 d797 124e cc38  ...b1.#.i....N.8
$ <<<CQr5YjGuI7hpkdeXEk7MOA== openssl base64 -d |xxd
00000000: 090a f962 31ae 23b8 6991 d797 124e cc38  ...b1.#.i....N.8

实际的密文是相同的，如果您分别删除或重新插入了第一个16个字节，则可以将1.xx文件解密为3.x或反之亦然；唯一的区别是前16个字节是否存在，这使BASE64 看起来不同，因为16不是3的倍数。

This isn't really programming or development and thus should be offtopic, but since you made me look:

Yes it changed, not specifically 3.0.2 but all 3.0.x (from an alpha of/before 3.0.0 through 3.0.3); see https://github.com/openssl/openssl/commit/c4c8791e145a7cb2d59e73410505e36e4d57ff78 . Now when you use -S it no longer writes or reads the 16 bytes consisting of Salted__ plus 8 bytes salt.

There is no option to control this. Of course since OpenSSL is open source you could fork and modify it as you wish, as long as you don't distribute it inconsistent with the license.

The apparent base64 difference is solely a result of this.

$ <<<U2FsdGVkX19VVVVVVVVVVQkK+WIxriO4aZHXlxJOzDg= openssl base64 -d |xxd
00000000: 5361 6c74 6564 5f5f 5555 5555 5555 5555  Salted__UUUUUUUU
00000010: 090a f962 31ae 23b8 6991 d797 124e cc38  ...b1.#.i....N.8
$ <<<CQr5YjGuI7hpkdeXEk7MOA== openssl base64 -d |xxd
00000000: 090a f962 31ae 23b8 6991 d797 124e cc38  ...b1.#.i....N.8

The actual ciphertext is identical, and a 1.x.x file could be decrypted by 3.x or vice-versa if you remove or reinsert, respectively, the first 16 bytes; the only difference is whether the first 16 bytes are there or not, which makes the base64 look different because 16 is not a multiple of 3.

回复收藏 0 原文