哪个“好"块加密算法的输出最短? [英] Which "good" block encryption algorithm has the shortest output?

问题描述

我想给客户一个看似随机的订单号，但在后端使用 0, 1, 2, ....这样客户会得到一个带有加密订单号的无密码保护的订单状态 URL，他们不能通过加减 1 来查看其他客户的订单号.这可能会取代生成随机订单密钥、检查唯一性的方案在之前的所有订单中，重新生成直到唯一.当 Web 服务器收到查看订单的请求时，它会解密订单号并检索订单.

I would like to give customers a random-looking order number but use 0, 1, 2, ... in the backend. That way the customer gets a non-password-protected order status URL with the encrypted order number and they cannot look at other customers' order numbers by adding or subtracting 1. This might replace a scheme where random order keys are generated, checked for uniqueness among all the previous orders, and re-generated until unique. When the web server gets a request to view an order, it decrypts the order number and retrieves the order.

为了保持 URL 简短，什么好的"加密算法具有最短的块大小?这个方案是个好主意吗?(如果我加密 Apple, Inc. 的员工 ID 以防止史蒂夫乔布斯要求员工 #0 怎么办?)

To keep the URL short, what "good" encryption algorithm has the shortest block size? Is this scheme a good idea? (What if I was encrypting Apple, Inc. employee ids to keep Steve Jobs from asking for Employee #0?)

请注意，所有包裹跟踪网站都允许您无需身份验证即可跟踪包裹.限制无密码订单状态页面上显示的信息量就可以了.

Observe that all the package tracking websites allow you to track packages without authentication. It would be fine to limit the amount of information shown on the password-free order status page.

推荐答案

出于安全原因，大多数分组密码将使用大于 32 位大小的块.

Most block ciphers are going to use larger than 32-bit sized blocks, for security reasons.

然而，我发现了一个专门为你正在做的事情制作的:Skip32

However, I found one that is made specifically for what you are doing: Skip32

您可能会考虑使用 GUID，但也许您有理由想要避免这种情况.(假设您的应用已经完成.)

You may consider using a GUID, but perhaps you have reasons you want to avoid that. (Say, your app is done already.)

实际上，如果 GUID 是允许的，那么它会给你一个 128 位的范围.您可以轻松使用任何其他分组密码.拥有更大空间(以长 ID 字符串为代价)的好处是，您将获得更多保护，防止人们猜测 ID.(并不是说它本身的订单 ID 应该是一个安全令牌......)

Actually, if a GUID is permissible, then that gives you a range of 128 bits. You could easily use any other block cipher. The benefit to having a larger space (at the cost of long ID strings) is that you'll have much more protection from people guessing IDs. (Not that it an order ID by itself should be a security token anyways...)

这篇关于哪个“好"块加密算法的输出最短?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！