-2

我可以轻松地手工制作我自己的加密算法，如下所示：

// make sure the private key is long enough
byte key[] = {0x3e, 0x33, 0x7e, 0x02, 0x48, 0x2a, 0x4e, ...};
byte data[] = "a string to be encrypted".getBytes("utf-8");
for (int i = 0, j = 0; i < data.length; ++i, ++j) {
    data[i] ^= key[j];
    if (j + 1 == key.length)
        j = 0;
}

使用上面的算法，如果我不把私钥泄露出去，我发现破解加密没有简单的方法（或者我太天真了？），如果可以像这样轻松创建加密算法，那么创建的意义何在标准？使用那些众所周知的算法有什么好处？

4

3 回答 3

3

为了不成为 Dave，您使用了一种众所周知的算法。

施奈尔定律指出，“任何人都可以发明一个如此聪明的安全系统，以至于她或他想不出如何破解它。”

这基本上意味着：不能假设安全系统（加密算法，身份验证系统......）是安全的，因为创建者说它是安全的。该主题的其他专家必须对其进行审查（并且通常审查很长时间）才能被认为是安全的。

于 2013-01-23T15:19:33.590 回答
3

直接与您提出的算法交谈，它存在几个主要问题：

  1. 如果您的数据比您的密钥长，那么恢复您的密钥将变得非常容易，因为它就像一个 Vigenere Cipher。

  2. 您只能使用密钥来加密单个消息。使用相同的密钥加密两条或多条消息会导致与在消息中重用密钥相同的问题，但更糟。

  3. 因为您的密钥必须与消息一样长才能真正安全，所以您将面临密钥管理的噩梦。您如何存储与消息一样长的密钥？您如何安全地将其传达给任何想阅读它的人？如果你想加密一个 1GB 的文件怎么办？您现在需要 2GB 的存储空间来存储您的加密版本

  4. 您的密钥必须是完全随机的。随机数生成器中的任何缺陷都会暴露有关您的消息和密钥的信息。诚然，这也是 AES 等算法的问题，但是虽然糟糕的 RNG 会减少破坏 AES 消息/密钥的工作量，但它并不像您的方案那样糟糕

像 AES 这样的众所周知的算法可以解决这些问题，使用短密钥来获得更高的安全性。单个 256 位密钥可用于在使用变得不安全之前加密大量消息，并且管理和存储 256 位密钥比 1GB 密钥容易得多。

于 2013-01-23T15:09:35.293 回答
1

使用众所周知的算法的主要好处是可以审查和分析它的缺陷和弱点。如果您自己滚动，您将无法获得社区审查的好处。此外，根据您的平台，使用内置加密可能几乎一样容易，或者同样容易。

我不是密码分析方面的专家，但这么简单的事情可能并不那么安全。

再说了，要是这么容易，大家不都做吗？

于 2013-01-23T14:50:47.227 回答