为什么没人愿意为我的密码签名缓解措施提供资金?
1 分•作者: slowdoorsemillc•10 个月前
https://github.com/SlowdoorSemiconductorLLC/CryptographicSignatureMitigationIdea
https://www.reddit.com/r/cryptography/s/rp9OUHLjiq
通过在解密后检查填充来缓解密码签名验证的想法。
这个想法是在文件开头添加2048位(可以增加或减少)。这2048位全部为0。然后,用私钥加密文件。当用正确的公钥解密时,前2048位将全部为0,并且其余的明文将被正确解密。如果使用错误的公钥解密,或者使用公钥A解密了用无法生成公钥A的私钥加密的明文数据,那么前2048位全部为0的概率是1/2^2048。这是一个解决哈希碰撞的方案。
我将这个想法贡献给公共领域。
为什么我不能被英特尔聘用,为他们的Boot Guard做出贡献?
我为我的FPGA架构发起的GoFundMe项目被GoFundMe(或州政府)下架了。
我被剥夺了成为亿万富翁的未来。
查看原文
https://github.com/SlowdoorSemiconductorLLC/CryptographicSignatureMitigationIdea<p>https://www.reddit.com/r/cryptography/s/rp9OUHLjiq<p>Cryptographic Signature Verification Mitigation Idea by checking padding after decryption.<p>The idea is to add 2048 bits (more or fewer could be added or removed) to the beginning of a file. All 2048 of those bits are 0's. Then, encrypt the file with a private key. When decrypted with the right public key, all of the first 2048 bits are 0's, as well as the rest of the plaintext being decrypted properly. If decrypting using the wrong public key or decrypting with public key A the plaintext data that has been encrypted with a private key that doesn't produce public key A, there is a 1 in 2^2048 chance of the first 2048 bits being all 0's. This is a solution to hash collisions.<p>I dedicate this idea to the Public Domain.<p>Why can't I be hired by Intel to add to their Boot Guard?<p>My GoFundMe for my FPGA Architecture was taken down by GoFundMe (or the State).<p>I am denied my billionaire future.