关于快速双向加密的建议?

发布于 2024-08-10 12:06:46 字数 366 浏览 2 评论 0原文

有人可以建议一种针对长整数的快速 2 路加密算法吗?

我的候选标准是:

  • AES:NIST FIPS-197 指定的高级加密标准。
  • BLOWFISH:由 Bruce Schneier 定义的 Blowfish 算法。
  • DES:NIST FIPS-46-3 定义的数据加密标准算法。
  • DESEDE:NIST FIPS-46-3 定义的“三重 DES”算法。

编辑 -

速度比安全更重要。实际的请求是“混淆”通过内部 Web 服务传递的 id,因此如果某个 id 被暴露,则无法通过添加 1 来猜测其他 id。(UUID 键的参数超过自动增量长整型??)

Can someone suggest a fast 2 way encryption algorithm for long ints?

My candidates are:

  • AES: the Advanced Encryption Standard specified by NIST FIPS-197.
  • BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.
  • DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.
  • DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

Edit -

Speed is more of a factor than security. The actual request was to "obfuscate" ids being passed over internal web services so in the event that an id is ever exposed one could not guess other ids by adding 1. (an argument for UUID keys over auto-increment longs??)

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

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

发布评论

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

评论(4

半山落雨半山空 2024-08-17 12:06:46

使用 AES。速度是其选择取代 DESEDE 的主要考虑因素。在现代 PC 硬件上,它往往比 Blowfish 更快,并且作为标准,它更有可能拥有专门的硬件支持。

顺便说一句,所有密码都加密长整数——每个字节流都是一个整数,以 256 为基数表示。

Use AES. Speed was a major consideration in its selection to replace DESEDE. On modern PC hardware, it tends to be faster than Blowfish, and as a standard, it's more likely to have specialized hardware support.

By the way, all ciphers encrypt long integers—every stream of bytes is an integer, represented in base-256.

绮烟 2024-08-17 12:06:46

我不需要公钥。要求是在数据库中的 id 在机器之间传递时对其进行加密。两台机器都会有盐

那么,XOR

I don't need a public key. The requirement is to encrypt ids in a database as they pass between machines. Both machines will have the salt

Then, XOR?

妳是的陽光 2024-08-17 12:06:46

您选择的首要标准是什么?速度还是安全?这是密码学行业的基本权衡。以下是一组 Crypto++ 基准测试结果。他们不会告诉您一切,但您将能够判断哪些算法通常比其他算法更快。这是讨论一些流行算法的相对优势的白皮书。在一般情况下确定强度是一件非常困难的事情,尽管一些算法已经得到了足够的关注,它们的优点和缺点是众所周知的(DES、RSA 等)。传统的经验法则是,按键越长意味着强度越大,但您必须非常小心。我怀疑在你的情况下,AES 或 Blowfish 都可以。 AES 可能会得到更广泛的支持,但实际上 - 任何一个都可以。除非速度是关键因素,否则请远离 DES。

What is your primary criterion for selection? Speed or security? That's the fundamental trade-off in the cryptography business. Here's a set of benchmark results for Crypto++. They won't tell you everything, but you will be able to tell which algorithms are generally faster than others. Here's a whitepaper discussing the relative strengths of some popular algorithms. Determining strength is a very hard thing to do in the general case, although some algorithms have been given enough attention that their strengths and weaknesses are fairly well known (DES, RSA, etc). A conventional rule of thumb is that longer keys imply greater strengths, but you gotta be very careful with that. I suspect that in your case, either AES or Blowfish will be fine. AES will probably be somewhat more widely supported, but really - either would probably do. Stay away from DES unless speed is a critical factor.

梦忆晨望 2024-08-17 12:06:46

如果安全性是您主要关心的问题,我会选择 AES。

但是,密文对于您的数据库来说可能太大。如果加上 IV、填充,则至少有 64 个十六进制字符。如果您遇到这样的限制,您可以使用我在这里发布的算法,

java 中 long 到 String(以及返回)的简单对称加密

If security is your main concern, I would go with AES.

However, the ciphertext may be too big for your database. If you add IV, padding, it's 64 chars in hex at least. You can use the algorithm I posted here if you ran into such limit,

simple symmetric encryption of long to String (and back) in java

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