我想给客户一个看起来随机的订单号，但在后端使用 0, 1, 2, ...。这样，客户将获得一个带有加密订单号的不受密码保护的订单状态 URL，并且他们无法通过加或减 1 来查看其他客户的订单号。这可能会取代生成随机订单 key 、检查唯一性的方案在所有先前的订单中，并重新生成直到唯一。当 Web 服务器收到查看订单的请求时，它会解密订单号并检索订单。
为了保持 URL 简短，什么“好的”加密算法具有最短的 block 大小？这个方案是个好主意吗？ (如果我对 Apple, Inc. 的员工 ID 进行加密以防止史蒂夫·乔布斯要求 Employee #0 怎么办？)
请注意，所有包裹跟踪网站都允许您无需身份验证即可跟踪包裹。可以限制无密码订单状态页面上显示的信息量。
最佳答案
除了你是否真的应该这样做的问题，这里有一个非常简单的带有固定 key 的分组密码(因为无论如何你似乎只需要一个排列)。
static uint permute(uint id)
{
uint R = id & 0xFFFF, L = (id>>16) ^ (((((R>>5)^(R<<2)) + ((R>>3)^(R<<4))) ^ ((R^0x79b9) + R)) & 0xFFFF);
R ^= ((((L>>5)^(L<<2)) + ((L>>3)^(L<<4))) ^ ((L^0xf372) + L)) & 0xFFFF;
return ((L ^ ((((R>>5)^(R<<2)) + ((R>>3)^(R<<4))) ^ ((R^0x6d2b) + R))) << 16) | R;
}
Skip32 就 32 位分组密码而言要好得多，但是当三行(长)行可以做到时，它有点重量级。 :-)
关于encryption - 哪个 "good" block 加密算法的输出最短？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/513056/