因此，您需要一个对称密码，其中加密和解密需要相同的密钥？（即，在使用Diffie-Hellman密钥交换或公钥加密（如RSA）或通过一些预先存在的秘密侧通道建立共享密钥后，您将使用的加密类型）。 很明显，如果你自己设计的话，你**don't expect it to be actually secure**，只是希望业余爱好者用手破解它并不容易，如果你做对了，而且使用它的应用程序/协议没有把它搞砸的话（例如，泄露密钥，不安全地重用密钥，或者生成弱密钥）。在Rijndael成为become AES in 2001的赢家之前，世界花了数年时间对密码进行评估，这是有原因的，也是为什么它如此复杂，而且是以128位为单位工作的。使用它来加密/解密更长的消息需要选择各种技术中的一种来应用块密码，而不是对每个128位的块分别重复完全相同的操作。例如密码块链接。（这样攻击者就可以知道明文是否有两个相同的128位块。）
如果你对消息的每个字节或单词重复相同的短密钥，那就是凯撒密码的数字等价物;即使是业余爱好者也很容易破解。 如果你有一个和消息一样长的密钥，那么它就是“one time pad“。（除非你使用相同的密钥和不同的明文，否则你已经破坏了安全性，因为攻击者可以将两个密文一起异或以取消密钥，并得到两个明文的异或。选择明文攻击将完全破坏这一点。）但如果你从来没有重用过真正随机的密钥，那么这是唯一一种可以证明是安全的加密技术。当然，它并不是很有用，因为你需要发送者和接收者已经有足够的共享秘密数据。如果你把一个间谍派到一个有密码本副本的地方，它就很有用，而对于无限期运行的独立计算机来说，它就没有用了。 因此，如果你从不重复使用密钥，简单的XOR和一个巨大的密钥是完美的，但如果你想重复使用一个密钥或有一个短密钥，它比更复杂的加密要弱得多。
这就是Stream Ciphers（如RC 4/RC 5）的工作原理，即它们是CSPRNG：密码学安全的伪随机数生成器。 就像一次性密码本一样，如果攻击者知道这一点的话，他们完全可以通过重复使用同一个密钥来击败。但是很明显，如果你正在设计自己的密码，你就不应该对真实的的安全性有任何期望。尽管如此，与其他一些混合的方法相比，在你的程序中硬编码一个密钥对这种策略来说会更糟糕。 对于这个玩具程序，你可以使用一个简单的不安全的PRNG，例如XORshift+。一个紧凑的xorshift 32+应该是可能的，在16位8086上有一对寄存器。我链接的主站点只有128和256位状态版本，但确实提到了16位CPU上的xorshift 32+。 然而，任何旧的简单的PRNG都可以使用，甚至可能是简单的LCG as a multiply / add with a constant，其中modulo是一个2^16的隐式模，只取AX中的16位结果。这只是几条指令。如果你关心真实的8086上的性能，你会避免乘法（因为它很慢）。
1条答案
按热度按时间j8ag8udp1#
因此，您需要一个对称密码，其中加密和解密需要相同的密钥？（即，在使用Diffie-Hellman密钥交换或公钥加密（如RSA）或通过一些预先存在的秘密侧通道建立共享密钥后，您将使用的加密类型）。
很明显，如果你自己设计的话，你**don't expect it to be actually secure**，只是希望业余爱好者用手破解它并不容易，如果你做对了，而且使用它的应用程序/协议没有把它搞砸的话（例如，泄露密钥，不安全地重用密钥，或者生成弱密钥）。在Rijndael成为become AES in 2001的赢家之前，世界花了数年时间对密码进行评估，这是有原因的，也是为什么它如此复杂，而且是以128位为单位工作的。使用它来加密/解密更长的消息需要选择各种技术中的一种来应用块密码，而不是对每个128位的块分别重复完全相同的操作。例如密码块链接。（这样攻击者就可以知道明文是否有两个相同的128位块。）
**最简单的方法是将明文与某个密钥进行XOR运算。**再次执行此操作将解密，因为XOR就是这样工作的。
如果你对消息的每个字节或单词重复相同的短密钥，那就是凯撒密码的数字等价物;即使是业余爱好者也很容易破解。
如果你有一个和消息一样长的密钥，那么它就是“one time pad“。（除非你使用相同的密钥和不同的明文，否则你已经破坏了安全性，因为攻击者可以将两个密文一起异或以取消密钥，并得到两个明文的异或。选择明文攻击将完全破坏这一点。）但如果你从来没有重用过真正随机的密钥，那么这是唯一一种可以证明是安全的加密技术。当然，它并不是很有用，因为你需要发送者和接收者已经有足够的共享秘密数据。如果你把一个间谍派到一个有密码本副本的地方，它就很有用，而对于无限期运行的独立计算机来说，它就没有用了。
因此，如果你从不重复使用密钥，简单的XOR和一个巨大的密钥是完美的，但如果你想重复使用一个密钥或有一个短密钥，它比更复杂的加密要弱得多。
一个好的策略可能是使用PRNG将一个小密钥扩展为任意长度的字节流，您可以将消息与进行XOR运算。即，密钥是随机数生成器的种子。（并且是程序的单独输入，或者可以将一个特定的密钥硬编码到玩具程序中。）
这就是Stream Ciphers（如RC 4/RC 5）的工作原理，即它们是CSPRNG：密码学安全的伪随机数生成器。
就像一次性密码本一样，如果攻击者知道这一点的话，他们完全可以通过重复使用同一个密钥来击败。但是很明显，如果你正在设计自己的密码，你就不应该对真实的的安全性有任何期望。尽管如此，与其他一些混合的方法相比，在你的程序中硬编码一个密钥对这种策略来说会更糟糕。
对于这个玩具程序，你可以使用一个简单的不安全的PRNG，例如XORshift+。一个紧凑的xorshift 32+应该是可能的，在16位8086上有一对寄存器。我链接的主站点只有128和256位状态版本，但确实提到了16位CPU上的xorshift 32+。
然而，任何旧的简单的PRNG都可以使用，甚至可能是简单的LCG as a multiply / add with a constant，其中modulo是一个2^16的隐式模，只取AX中的16位结果。这只是几条指令。如果你关心真实的8086上的性能，你会避免乘法（因为它很慢）。
要考虑的另一个主要策略是一系列的rotate、XOR和ADD，就像现在已经过时的DES. https://en.wikipedia.org/wiki/Data_Encryption_Standard。（也可能是shift，但是rotate和XOR很容易可逆，因为它们不会破坏信息。）
一个简化的，可能更小的版本（例如，使用32位块，这样你就可以只使用一对
adc ax,ax/adc dx,dx指令循环一次）可能会工作得很好。有一个微型加密算法（wikipedia has a C version），它基于Feistel轮（双向移位，添加魔术常数，一起异或），并且旨在实现起来便宜+简单，尽管已经发现了它的一些弱点。（尽管它确实有128位密钥和64位块大小。）在this question中实现32位x86 asm的失败尝试。
在8086上移位4或5并不便宜（需要CL中的计数，除非你可以滥用
AAA或其他东西来分割4位半字节，使用比aam 16更便宜的东西来进行硬件除法，甚至更慢）。如果你不关心完整的安全性，做远少于建议的每块64轮的操作将有助于性能，但不一定会影响代码大小。**对于业余爱好者来说，用相同的密钥加密不同的消息应该比用流密码更容易破解。**对于有经验的密码学家来说，甚至可能更难破解。
你仍然可以在每一步都使用一个PRNG来演化密钥，比如xorshift+或者其他更简单的方法，这样如果4个字母恰好对齐，它们就不会每次都以相同的方式加密。或者如果你不在乎这个，并且需要代码长度保持很小，你可能会给予这个方法。或者只是在每一步都增加密钥。或者进行密码块链接，将新块的明文与先前的密文进行XOR运算。这只是一篇Wiki文章中的一部分，介绍了在大数据流上使用块密码算法的各种方法。
解密和加密在此策略下不是同一个功能;你需要以相反的顺序做事情。