将订单号模糊/加密为另一数字：对称，“随机”出现？ [英] Obscure / encrypt an order number as another number: symmetrical, "random" appearance?

问题描述

客户端有一个简单的增加订单号（1，2，3 ...）。他希望最终用户收到一个8位或9位数字（仅数字 - 无字符）随机数字。显然，这个随机数字实际上必须是唯一的和可逆的（它实际上是实际的数字编号的加密）。

Client has an simple increasing order number (1, 2, 3...). He wants end-users to receive an 8- or 9- digit (digits only -- no characters) "random" number. Obviously, this "random" number actually has to be unique and reversible (it's really an encryption of the actualOrderNumber).

我的第一个想法是洗牌一些。当我向客户显示一个样本序列时，他抱怨说，随后的obfuscOrderNumbers正在增加，直到他们进入洗牌点（低阶位开始播放的点）。他希望obfuscOrderNumbers是尽可能随机的。

My first thought was to just shuffle some bits. When I showed the client a sample sequence, he complained that subsequent obfuscOrderNumbers were increasing until they hit a "shuffle" point (point where the lower-order bits came into play). He wants the obfuscOrderNumbers to be as random-seeming as possible.

我的下一个想法是确定性地种子线性同余伪随机数发生器，然后取实际的值。但是在这种情况下，我需要担心碰撞 - 客户想要一个算法，保证不会在至少10 ^ 7个周期内发生冲突。

My next thought was to deterministically seed a linear congruential pseudo-random-number generator and then take the actualOrderNumber th value. But in that case, I need to worry about collisions -- the client wants an algorithm that is guaranteed not to collide in at least 10^7 cycles.

我的第三个想法是呃，只是加密darn的东西，但是如果我使用库存加密库，我必须后处理它来获得8位或9位只有要求。

My third thought was "eh, just encrypt the darn thing," but if I use a stock encryption library, I'd have to post-process it to get the 8-or-9 digits only requirement.

我的第四个想法是将actualOrderNumber的位解释为灰色编码的整数并返回。

My fourth thought was to interpret the bits of actualOrderNumber as a Gray-coded integer and return that.

我的第五个虽然是：我可能是反思这个，我打赌StackOverflow的人可以在几行代码中做到这一点。

My fifth though was: "I am probably overthinking this. I bet someone on StackOverflow can do this in a couple lines of code."

推荐答案

客户端是否需要分发混淆的连续订单号码，特别是什么？

Will the client require the distribution of obfuscated consecutive order numbers to look like anything in particular?

如果您不想使加密复杂化，请使用一些随机盐析的组合（如果您有空位的位/数字），则XOR叠加在某个固定常量上（或某些功能随时随地可用于混淆的订单ID，例如放置订单的 customer_id ）

If you do not want to complicate yourself with encryption, use a combination of bit shuffling with a bit of random salting (if you have bits/digits to spare) XOR-superimposed over some fixed constant (or some function of something that would be readily available alongside the obfuscated order ID at any time, such as perhaps the customer_id who placed the order?)

编辑

似乎所有客户端的需求都是一个外部聚会不能推断销售进度。在这种情况下，混洗解决方案（比特映射，例如原始位1映射到模糊位6，原始位6映射到模糊位3等）应该是足够的。添加一些随机位，如果你真的想让它更难破解，只要你有额外的位可用（例如，假设原始订单号码最多只能达到6位数字，但是您可以在混淆的订单号中使用8-9，那么在执行位映射之前可以使用2-3位随机数）。可能XOR是额外的恐吓的结果（好奇的一方可能会尝试生成两个连续的混淆命令，XOR他们相互抵消，以摆脱XOR常数，然后必须推断哪个非零位来自盐，哪些来自一个增量，以及他是否真的有两个连续的订单号？他必须重复这一点，他希望是连续的订单号才能破解。）

It appears that all the client desires is for an outside party to not be able to infer the progress of sales. In this case a shuffling solution (bit-mapping, e.g. original bit 1 maps to obfuscated bit 6, original bit 6 maps to obfuscated bit 3, etc.) should be more than sufficient. Add some random bits if you really want to make it harder to crack, provided that you have the additional bits available (e.g. assuming original order numbers go only up to 6 digits, but you're allowed 8-9 in the obfuscated order number, then you can use 2-3 digits for randomness before performing bit-mapping). Possibly XOR the result for additional intimidation (an inquisitive party might attempt to generate two consecutive obfuscated orders, XOR them against each other to get rid of the XOR constant, and would then have to deduce which of the non-zero bits come from the salt, and which ones came from an increment, and whether he really got two consecutive order numbers or not... He would have to repeat this for a significant number of what he'd hope are consecutive order numbers in order to crack it.)

EDIT2

当然可以为混淆顺序ID分配完全随机数，将对应关系存储到持久存储（例如DB），并执行冲突检测以及对相同存储进行去混淆。如果你问我一点点，但在正面方面，它是最好的混淆方式（你实现你的灵魂所要求的任何分发功能，和，你可以随时改变分发功能。）

You can, of course, allocate completely random numbers for the obfuscated order IDs, store the correspondence to persistent storage (e.g. DB) and perform collision detection as well as de-obfuscation against same storage. A bit of overkill if you ask me, but on the plus side it's the best as far as obfuscation goes (and you implement whichever distribution function your soul desires, and you can change the distribution function anytime you like.)

这篇关于将订单号模糊/加密为另一数字：对称，“随机”出现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！