我需要一个不使用密钥的简单加密算法。
你们推荐哪些？
如果我使用内置的加密方法，形成身份验证呢？（我忘记了它的方法/命名空间）。
不使用密钥的加密算法
4
- Blankman
9
4没有密钥就无法加密内容。如果没有密钥，那么要么任何人都能恢复明文，要么对于所有人来说都是无法恢复的。 - erickson
12公开的字符串加密函数，输入为msg（信息），返回加密后的字符串"secret!!"。 - Juliet
1@Princess: public string decrypt(string msg, string realmsg) { return realmsg;} // 解密甚至更简单！ - belgariontheking
6我认为如果你不知道答案，问这个问题是合理的，这就是这个网站存在的意义。投票反对这个问题的人：嘘。 - Shane C. Mason
2我同意Shane的观点。正如Jeff Atwood所说，唯一愚蠢的问题是刚被回答过的问题。对于新手来说，这是一个合理的问题。或者也许就像船舶编程一样。无论哪种方式，这都可能帮助刚开始学习的人。 - erickson
显示剩余4条评论
8个回答
16
每个对称加密方案都有一个密钥。如果你正在寻找一种不需要自己管理密钥的加密方案，可以尝试使用数据保护 API，在 .NET 中（2.0及以上版本）以 System.Security.Cryptography.ProtectedData 类的形式公开。它使用机器或用户的凭据作为加密密钥，提供任意数据的对称加密。
byte[] plaintextBytes = GetDataToProtect();
byte[] encodedBytes = ProtectedData.Protect(plaintextBytes
, null
, DataProtectionScope.CurrentUser);
请看我在这里的另一个答案，获取更详细的信息。
- Michael Petrotta
1
Mac OS 有它的“keychain”，类似于此的东西。有人知道 Linux 上是否有类似的东西，或者更具体地说是 RH AS 5 吗？ - erickson
8
加密需要使用被加密对象之外的东西，因为你需要这个东西来解密。这个外部的东西就是密钥。没有密钥就没有有用的加密，只有哈希。
- Welbog
6
你所称之为加密实际上只是混淆。即使如此，它也将是一种嵌入算法的加密方式。在你提供至少一个简单的使用案例之前，你不会得到任何合理的答案。
- Jherico
1
2这是一个很好的观点，需要注意的是，通常混淆是完全可以接受的。 - Shane C. Mason
4
rot13使用算法中已经存在的密钥。我认为这是你能得到的最接近的答案。
- belgariontheking
10
7“13”是需要解密的东西。尽管它已经硬编码到rot13算法中，但这并不意味着它不是一个密钥。 - Welbog
1我几乎不会把rot13称为“加密”。 - rlbond
1@BTK：你第一次说得对。ROT-13中的13不是密钥，如果你把它构建到算法里面的话。密钥是与明文、密文或算法分离的东西。就像你之前说的一样，如果你将其实现为ROT-X，并让用户提供X，则它是一个密钥。 - Bill the Lizard
1@Bill： "键"的概念比你想象的更抽象。接受rot13算法作为黑盒子，你需要使用rot13黑盒子来解密它创建的消息本身就是一种密钥的想法。 - Welbog
2@Welbog：密钥与算法是分开的。黑盒算法本身并不构成密钥。http://en.wikipedia.org/wiki/Key_(cryptography)。如果我的加密算法是以只有我知道的方式对消息的字节进行混淆，而我的解密算法是反转混淆步骤，那就不是密钥。ROT-13只是这个过程的一个非常简单的实例。 - Bill the Lizard
显示剩余5条评论
3
作为对于无密钥 = 无加密的讨论的补充...
也许你真正想要的是自动且安全地创建和交换密钥，而不需要用户交互。这可以通过使用非对称加密来实现，它的工作原理如下：
场景：A需要向B发送一条消息，并希望确保没有人能够在中间读取该消息。
A和B像这样开始一次会话：
1. A请求B的公钥。 2. B生成一个公钥/私钥对，并将公钥发送给A。 3. A使用公钥加密消息并发送消息。 4. B接收消息并使用其私钥解密消息。
这种方法有效的原因是该消息是用公钥加密的，只有相应的私钥才能解密。因此，公钥不必保密。如果中间人获取了公钥，他也无法使用它来解密消息。
如果你搜索非对称加密，你可能会找到大量相关信息...
也许你真正想要的是自动且安全地创建和交换密钥，而不需要用户交互。这可以通过使用非对称加密来实现，它的工作原理如下：
场景：A需要向B发送一条消息，并希望确保没有人能够在中间读取该消息。
A和B像这样开始一次会话：
1. A请求B的公钥。 2. B生成一个公钥/私钥对，并将公钥发送给A。 3. A使用公钥加密消息并发送消息。 4. B接收消息并使用其私钥解密消息。
这种方法有效的原因是该消息是用公钥加密的，只有相应的私钥才能解密。因此，公钥不必保密。如果中间人获取了公钥，他也无法使用它来解密消息。
如果你搜索非对称加密，你可能会找到大量相关信息...
- Arjan Einbu
2
无钥匙加密的问题在于一旦被破解，就对所有人都失效了。以微软脚本编码器为例，一旦有人发现如何反向加密并将其公开，加密就会对所有人失效（有关此情况并不像听起来那么糟糕的详细信息，请参见评论）。尽管如此，您仍然可以使用任何钥匙算法并保持密钥保密，但也会产生同样（不好的）效果。
- Bill the Lizard
4
2该系统并没有“变得无用”; 它仍然完全适用于设计它的目的。防止决心攻击者解码不是我们设计时的目标之一。我们知道它会在第一天被破解。该系统的目标是迫使想窃取脚本源代码的人们必须使用解密工具。他们必须故意使用解密工具表明了恶意意图，这可以被起诉。 - Eric Lippert
@Eric：我改正了。从网站上来看，“请注意，这种编码只能防止对您的代码进行随意查看；它无法阻止决心强烈的黑客查看您所做的事情和方式。” - Bill the Lizard
1最终，无论编码器是否是一个好主意，都是一个有争议的问题。这是因为(1)在用户模式代码运行时编译源代码的情况下，强加密是不可能的；(2)关于所提出的违反“不得逆向工程”的合同的证据是否可在法庭上使用的法律问题也存在争议。但是我们的客户调研显示，许多客户非常需要这个功能，即使他们知道它的缺点。因此，我们实现了它。 - Eric Lippert
@Eric：感谢您为我澄清这些问题。法律问题是一个有趣的话题。 - Bill the Lizard
2
基本上，密码是让Alice告诉Bob一些信息，即使Eve窃听也无法破解的方法。
这意味着密文必须有某种方式来区分Bob和Eve。
通常，这是一个密钥。现在，它可以是Alice提供给Bob而不是Eve的对称密码密钥，或者是Bob广播的非对称密码密钥，以便任何人都可以为他加密一条只有他能读取的消息（通常用作传输对称密码密钥的一种方式）。
算法可以作为密钥，但算法真的很难分发和保密。最好使用标准密钥。
如果你愿意相信Bob会努力阅读消息而Eve不会，那么你可以简单地混淆明文。例如，你可以将文件压缩。Eve不能直接阅读它，她必须解压缩它。这通常是为了防止Eve偶然读到为Bob准备的信息，假设Eve是诚实的但可能偶尔会犯错误。我想到的例子是CVS密码文件；它将防止系统管理员一眼看到密码，但如果有人真的想读它，它就是“rot13的道德等价物”。
因此，为了给你一个有用的答案，我们需要知道你想用它做什么。数据有多敏感？它容易落入不友好的手中吗？你希望谁能读到它？
顺便说一句，永远不要自己编写加密算法。很容易出错，但很难注意到。使用标准算法的标准实现。
这意味着密文必须有某种方式来区分Bob和Eve。
通常，这是一个密钥。现在，它可以是Alice提供给Bob而不是Eve的对称密码密钥，或者是Bob广播的非对称密码密钥，以便任何人都可以为他加密一条只有他能读取的消息（通常用作传输对称密码密钥的一种方式）。
算法可以作为密钥，但算法真的很难分发和保密。最好使用标准密钥。
如果你愿意相信Bob会努力阅读消息而Eve不会，那么你可以简单地混淆明文。例如，你可以将文件压缩。Eve不能直接阅读它，她必须解压缩它。这通常是为了防止Eve偶然读到为Bob准备的信息，假设Eve是诚实的但可能偶尔会犯错误。我想到的例子是CVS密码文件；它将防止系统管理员一眼看到密码，但如果有人真的想读它，它就是“rot13的道德等价物”。
因此，为了给你一个有用的答案，我们需要知道你想用它做什么。数据有多敏感？它容易落入不友好的手中吗？你希望谁能读到它？
顺便说一句，永远不要自己编写加密算法。很容易出错，但很难注意到。使用标准算法的标准实现。
- David Thornley
1
如果你真的想要混淆代码，可以使用PasswordDeriveBytes类从密码中创建一个密钥。然后在AES等加密算法中使用该密钥。
- chris166
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接