这是场景：

你做错了。不在分裂之类的；但在思考。AES 加密如果处理得当，不会被“破解”。AES 是您系统中最强大的部分；这是您应该担心的最后一部分。

AES 加密提供的是一个非常具体的功能：使用给定的密钥 K，它将一段数据（“明文”）转换为不可读的东西（“密文”） ，除了那些知道K的人，因为知道K允许用于反转转换。只要攻击者不知道K，加密数据就是安全的。如果攻击者知道K，那么他们就赢了，再多的分裂、交换或围着火跳舞，同时吟唱伟大精神的荣耀，都无法拯救你。

AES 使用 128、192 或 256 位的密钥。有这么多可能的密钥，攻击者通过纯粹的运气破坏密钥的概率是无限小的。128 位密钥就足够了；较大的密钥并不是为了提高安全性，而是为了在您的开发人员中维护您的阿尔法男性地位。

如果你真的需要进行复杂的数据洗牌仪式，例如，让你的老板得到“安全正在发生”的印象并且你没有懈怠，那么你不妨好好做。不要分裂；相反，给定一个字节序列C（加密字符串），生成一个相同长度的随机字节序列D；然后将C “拆分”为两份C ₁  =  C  XOR  D和C ₂  =  D。要组装这些共享，只需将它们异或在一起：碰巧C ₁  XOR  C ₂  =  C. 这种分裂显然是安全的（学习C ₁或C ₂的攻击者，但不能同时学习两者，从信息论的意义上讲，什么都学不到，这与任何加密都可以得到一样好）。当然，前提是你不会搞砸事情（你必须生成一个强随机D，并且每次你有一些要“拆分”的字符串时都生成一个新的）。

您应该担心 AES 密钥的安全存储，而不是分解数据。如果密钥被泄露，那么根据Kerckhoffs 的原则，您对数据所做的处理实际上不会有任何影响。

编辑添加：最特别的是，您不能将 AES 密钥存储在保存加密数据的同一数据库中，因为数据库泄露将产生密钥和数据。即使整个操作系统没有受到威胁，有时也可以通过 SQL 注入等方式破坏远程数据库。将密钥存储在别处是纵深防御的一部分。理想情况下，它将使用硬件安全模块 (HSM) 进行存储，但编译成程序甚至作为文件系统中的文件要比存储在数据库中好得多。

我可以建议您重新考虑解决此问题的方法。你在哪里存储数据？如果它在数据库中，大多数数据库都能够相当安全地加密静态数据。数据是否需要通过不安全的渠道移动？查看 HTTPS 或安全 FTP。除非你绝对有，否则不要乱用加密货币。非常容易出错。