@aheadlead 原始信息作为十六进制字符串是

```
7fa79321e469c67de26ec1edb750b96b3294e2c291689e85075e613bcd09d5d9
```

你的答案好像是对的，但多了一些莫名的符号。

请问您是怎么解密的呢？

允许在 readme 里能播放外链的视频，可以限制视频的大小和时长。

@soulzz 肯定没这个好。canvas 做不出玻璃的材质来。

@nicoljiang 所有维都是一样的

老师让我来给大家讲堂课，我思来想去，实在不知道讲什么好，心里想，怎么就钦定了我呢？还是令请高明吧！咱们有句老话，闷声发大财，这是坠吼的。但是我又一想，一句话不说也不好，也罢，大家一起跟我念：

苟

我觉得附上一个对 python/ruby/lua 的 hash 算法的分析更好，让大家看看工业界是怎么算散列表的。

上硬件加密是可以的，但是成本最好比较低，而且我考虑第一版初步的程序先不要那么高级，不然搞不出来交不了差就不好了。

@Cryse
@tabris17

不行，软件比较复杂，必须放在客户端跑，公司没有能力支持那么复杂的云服务器。加密狗的话每套成本要增加小 100 左右，也不好。

@luny 我找到一个淘宝链接，他卖 3 毛。我不太懂的是这个应该怎么用？是写好程序烧进去，然后集成到硬件上？可以解释下吗？

@luny 淘宝上有卖？能给个地址吗？

@murmur 是这样的，我们这个原则上就是防君子不防小人，有个基本的保密功能而已。而且我们在考虑增加一个后台发送信息的功能，把动态计算出的哈希值 H 发到我们的服务器上和数据库进行比对，这样他只能伪造硬件信号。

@zzzzzzZ 意思是说用任意的 (E', Pub_Key') 替换掉原本的 (E, Pub_Key) ，使得验证总能通过是吧？那前提是要反编译找到程序中的 (E, Pub_Key) ？

@jim9606 是这样的，硬件信息是可以作伪的，所以我们这个理论上是可以破解的，防君子不防小人而已。但我们本也没打算弄得很坚不可摧。

@geelaw 软件里面会和事先存储的 E 比较，这个 E 是用 Priv_key 加密得到的，他拿不到 Priv_Key，当然就不知道 E 是多少。除非他跳转的方法找到了 E 的存储地址，但是这个只对单个产品有效。

还有，RSA 里面公钥私钥都可以用其中一个来加密，另一个来解密，二者的地位是相同的。我这里是 "任何客户端都可以解密，但是对方无法从解密算法反推出加密算法"，这样避免对方写出注册机啊。

@594duck 要是公司买一套方案，还招我做啥。

@yukiww233 　可否多说几句解释下？

@yksoft1ex 先不说壳，我这个方案有什么问题吗？我们这个程序只是一个辅助，也不能太复杂。

开头英文版链接直接写 English VERSION HERE 就可以了。 而且我建议把 README 设为英文版，在开头加个中文版链接。毕竟英文受众确实更多。