字符加密的字符

Question

是否有任何可用的库/算法具有基于字符的加密机制的字符。我的基本含义是，如果输入文本为someText，则加密文本应具有相同数量的字符。

从我们对非对称加密机制的探索中，我们觉得通过这种方式无法实现字符加密的特性。

最好是解决方案是基于“密钥”的解决方案，因为我们需要通过不同的应用程序加密输入文本[其中一个实际上是自定义硬件中的嵌入式应用程序 - 并且制造商更喜欢基于密钥的加密逻辑]。丢失我们的密钥的安全威胁并不重要，并且是可接受的风险。

Answer 1

您想要使用流密码，或者（如果您的用例证明合理）使用一次性密码。一次性垫是一种痛苦 - 你需要以某种方式获得接收方的密钥，密钥必须至少与明文一样长，并且处理所有问题时存在很大的困难如果存在传输错误，则会发生 - 因此流密码可能是最佳选择。

RC4可能是适合您的算法。

您是否有必须进行字符加密的特殊原因？像AES这样的对称算法倾向于使用小块大小，通常是64位，因此不太可能增加太多的空间开销。如果你可以使用对称分组密码，那么这可能会让你更容易。

我不确定基于“密钥”的解决方案是什么意思。所有现代加密算法都是键控的，但密钥的性质会根据算法而变化。对称密码通常具有共享密钥，非对称算法是使用公钥/私钥的算法。根据{{​​3}}，有不同的流密码使用任一类型的密钥。

我还有点不确定你的意思是“失去我们的密钥的安全威胁并不重要，并且是可接受的风险。”如果丢失了密钥，则不再进行加密（至少在旋转密钥之前）。如果没有加密是可以接受的，那么为什么你首先要加密？如果只是模糊数据就足够了，那就完全不同了。

Answer 2

您是否考虑过XOR加密？

http://en.wikipedia.org/wiki/XOR_cipher

这是Java示例：

http://www.ecestudents.ul.ie/Course_Pages/Btech_ITT/Modules/ET4263/More%20Samples/CEncrypt.java.html

Answer 3

对于与明文长度相同的密文，您需要在CTR模式下使用流密码或块密码。对于流密码，RC4很常见但是过时了。 eSTREAM Profile 1投资组合中有更好的流密码。对于块密码，在CTR模式下使用AES而不填充。

Answer 4

诀窍是将角色转换为角色，然后以不需要更多角色的方式将角色转换为角色。从数学上讲，如果您使用流密码（它们执行1：1位加密），您就可以这样做。唯一的问题是你会留下一个＆＃34; partial＆＃34;可能不合适的位。我创建了这样一个程序只是为了它的乐趣。由于它依赖于巨大的乘法和除法，我很快发现这是可撤销的性能明智。

所以基本上，你需要的是具有N个字符的字母表，其中N = 2 ^ x。在这种情况下，你只需要转移等。或者，如果你有空余，你可以查看文本并组合字段，使它们的大小更接近N（任何N）。

您所做的是将字段映射到范围0..N，将其放在X位中，将它们连接在一起并对其进行流加密。你现在应该仍然拥有相同的位数。然后将结果映射回原始字母并存储/发送。

这是一个想法，我已经在脑子里骑了一段时间，我从来没有向任何人解释过。如果有任何问题，请告诉我。