为什么没有人愿意给我资金来支持我的密码签名减轻方案？
以下内容翻译成中文：
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.