利基市场,可能的朴素数字消息签名
我的目标是一种轻量级的消息签名,类似于 PGP,只不过只需要一个私钥,不需要公钥关联。目标仅仅是防止两个可信实体之间的字符串被篡改。它从可信源开始,通过互联网,然后到达另一个可信目的地。
我想知道我的天真的方法是否安全。因为签名算法实际上不会被强制执行。
1) 源和目标都有一个“私钥”,它只是 uuidgen 生成的一个非常随机的数字。
2) 源有一个打算发送到目的地的字符串。
3) Source 将有效负载字符串与私钥连接,然后对结果进行 sha1,以生成签名。
4) 得到的明文值+签名成对发送到目的地。 “hello//SIG:12345ABCDEFG”
5) 目的地接收签名变量,用其已知的私钥生成签名,并再次将签名与接收到的数据配对进行比较。如果它们匹配,则被接受。
其变体将包含一个四舍五入到小时的 unix 时间戳,使签名过期。
我担心的是,在给定一组选择性的数据有效负载的情况下,暴力破解私钥并使用这种方法分析生成的签名是否可行。
谢谢
My goal is a lightweight kind of message signing, comparable to PGP, except there is only a need for one private-key, no public-key associate. The goal is merely to prevent tampering of a string between two trusted entities. It starts from a trusted source, goes over the internet, then arrives at another trusted destination.
I would like to know if my naive approach is secure. In that the signing algorithm would not be practically brute forced.
1) Both source and destination have a "private key" which is just a very random number generated by uuidgen.
2) Source has a string it intends to send to destination.
3) Source concatenates the payload string with the private key, and then sha1's the result, to produce a signature.
4) The resulting plain-text value + signature are sent to destination in a pair. "hello//SIG:12345ABCDEFG"
5) Desination receives the signed-variable, generates a signature with its known private-key, and compares agains the signature paired with the received data. If they match, it is accepted.
A variation of this will incorporate a unix timestamp rounded to the hour, making the signature expire.
My concern is if it would be feasible to bruteforce the private key given a selective set of data payloads and analyzing the resulting signatures with this approach.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
看来您想要实现的目标与 HMAC 非常相似(维基百科上的文章)。
对于 HMAC,您需要执行一些附加步骤将消息和密钥组合成哈希。这使得生成的散列比简单地连接原始消息和秘密密钥并对其进行散列所产生的散列更难攻击。
如果您想尽可能多地使用加密标准(在我看来,这几乎总是一件好事),我会考虑按照 HMAC 定义规定的方式进行操作。为了使签名过期,我只需将过期日期附加到消息中,然后构建该组合字符串的 HMAC。
It seems like what you want to achieve is very similar to an HMAC (article on Wikipedia).
For an HMAC, you perform some additional steps to combine message and secret key into a hash. This makes the resulting hash harder to attack than one which results from simply concatenating original message and secret key and hashing that.
If you want to use cryptographic standards as much as possible (which - in my opinion - is almost always a good thing), I would look into doing it the way the HMAC definition prescribes. To make the signature expire, I would simply attach the expiration date to the message and then build the HMAC of that combined string.