根据您的描述，他们所做的是在某些 SSL 中传输数据（这是合理的），但在 Javascript 中添加了一个额外的加密层（这是不合理的）。整个推理是错误的。事实上，要么 SSL 确保传输的安全性，在这种情况下，额外的层就毫无用处；或者 SSL不能确保传输的安全性，然后攻击者可以修改发送的 Javascript 代码，从而消除任何希望从额外加密中获得的安全收益。

实际上，如果 SSL 还不够，那么你已经注定了。基本上有两种方式可以拦截 SSL 连接：

• 攻击者可以在客户端机器中植入他控制的额外根 CA 证书；然后，他通过即时为服务器生成一个伪造的证书来运行中间人攻击，该证书由攻击者控制的 CA 签名。这种方法通常在一些大型组织中应用，使用 Blue Coat 的ProxySG 设备等产品。

• 攻击者可以在客户端机器中植入一些软件，这些软件挂钩客户端浏览器使用的 SSL 库，并在加密之前（或在解密之后，用于传入数据）直接从源读取数据。

第一种方法是爱管闲事但诚实的系统管理员所做的；它可以很好地扩展并且可以抵抗浏览器升级。它也没有第二种方法那么谨慎，因为用户总是可以单击挂锁图标，查看明显的服务器证书链，并注意额外的根 CA。

这两种方法都需要对客户端计算机进行相同类型的初始访问，因此如果攻击者可以使用其中一种，那么他也可以使用另一种，而您也不会更聪明。简而言之：如果 SSL 还不够，那么您的机器就会受到损害，抵抗是徒劳的。任何能够突破 SSL 的人也可以并且可能更容易地在机器上安装一个键盘记录器，甚至不再为 SSL 烦恼。

“xAES”值得拥有自己的部分。

首先，不存在“专利专有算法”之类的东西。专利是一种出版物，这甚至是它存在的理由。专利是一项发布发明的交易，以换取对其使用的临时垄断。整个想法是为了防止发明丢失，因为发明者依靠保密，然后死了。专利是否对软件“起作用”是一个公开的（和激烈的）争论，但基本属性仍然存在：根据定义，获得专利的专利也会被公布。

因此，如果该算法真的获得专利，那么专利应该存在并且他们应该能够向您发送对它的引用（专利号）。但是如果没有任何参考，就不得不假设该专利可能不存在，这意味着他们在对您撒谎（建立信任的好方法）。

现在让我们看看一些细节。AES是一种具有精确定义的算法，建立在代数性质的一些基本组件之上。在过去的 15 年中，对这些组件之间的相互作用进行了详细的研究，关于该主题的压倒性共识是，这些事情是微妙的，要确保任何给定的定义都能确保适当的安全级别并不容易。因此，任何单个更改都可能对安全性造成极大损害，并且没有明显的方法可以检测到这种情况。

使用“更复杂和更长的多项式（在步骤 MixColumn 中）”的概念没有意义。该步骤在AES 标准中定义为对应于列（在 GF(256)[X] 中作为多项式）乘以常数多项式P，以特定的 4 次多项式M为模。由于一列有四个字节，所以M的度数只能是4；没有其他选择；并且由于运算是模M完成的，因此P的次数不能超过 3。因此，使用“更长的多项式”是没有意义的。

（或者，也许更糟的是，它们确实与具有更大次数的多项式P'相乘，但没有意识到这相当于在模M时与次数为 3 或更少的多项式相乘。）

AES 中 MixColumns 变换的作用是保证一些雪崩效应。一个简单的观点是“更多的雪崩”更好，但这首先要求标准的 MixColumns 在这方面是有缺陷的，这是一个未经证实的断言。此外，更强的雪崩效应实际上与在人类眼中看起来“更复杂”的多项式并不相关。

当然，8192 位的密钥大小非常可笑。128 位已经足够了，这是有充分理由的。密钥大小不是对称密码算法的弱点；当 Disco 还很新颖时，它曾经是一个弱点，因为有一些广泛使用的算法具有非常短的键（特别是DES）。但是情况发生了变化，对称密钥被扩展为可以免受暴力攻击，不仅来自现有的硬件，还包括在可预见的未来发明的硬件。

当有人说“我使用 8192 位对称密钥”时，我听到的是：“我不知道密码学是什么，但我真的很喜欢大数字”。

最后但并非最不重要的一点是，过去十年密码学研究的一个共同主题是边信道攻击是一个可能的问题，应该在密码算法的实施中加以注意。已经有很多关于这个主题的研究，特别是 AES S-box（例如这个）的优化的基于电路的描述，以促进恒定时间位片的实现。通过修改算法元素，他们简单地放弃了所有的研究。

摘要：我建议避免使用该产品，因为：

• 他们提出没有支持或毫无意义的声明（例如，同样保密的专利算法）。
• 如果他们真的按照他们声称的去做，那么他们基本上会破坏所有外部审查的尝试，这是一个问题，因为密码算法中的所有安全性都来自外部审查。
• 安全模型不成立；或者更确切地说，他们没有描述任何安全模型，其中所有额外的自定义加密都会对安全产生任何实际影响。
• 密码算法的描述充满了流行语，这些流行语通常与完全缺乏密码技能相关。
• 无论如何，所有这一切都归结为：您将宝贵的数据发送给这些人，而您无法知道他们如何处理这些数据。所有的加密讨论都是关于传输中的安全性，但真正的弱点总是在端点。在他们的网站上，他们用一个通用的“我们位于冰岛”来解决这个问题。究竟生活在活火山之上或拥有蓬勃发展的渔业应该如何提高数据安全性，尚无定论。

如果没有适当的密码分析，肯定没有什么好说的，但这听起来很警钟。

首先，密钥交换算法。秘密永远不会明文发送，这很好，但它是通过网络发送的，这是不好的。双方都有办法以任何方式共享一个永远不会通过网络发送的秘密。参见例如Diffie-Hellman。或者它是使用椭圆曲线的版本。好在他们使用了一个临时密钥，但是他们有针对MITM 攻击的保护吗？

第二，通讯关键。它似乎是由客户端生成的。并且依赖于客户端的伪随机数生成器。计算机不擅长生成随机数，而 javascript（具有不更难访问可以收集一些熵的操作系统）甚至更糟。因此，通信的关键仅取决于一个可能很差的伪随机数发生器。不好，它可能取决于客户端和服务器。

第三，xAES。虽然他们可能已经对其进行了一些改进，但这是不可能的。更有可能的是，它们稍微扰乱了阶段之间所需的交互，使结果的安全性大大降低。在野外有很多这样的尝试，其中大多数都比原来的要糟糕得多（也就是可以立即破解）。

第四，xAES 密钥长度。这一个值得它自己的段落。虽然密钥大小通常越多越好，但 8192 密钥大小听起来不合理。这种密钥大小对于非对称算法很常见，它需要更长的密钥大小（参见例如https://crypto.stackexchange.com/questions/6236/why-does-the-recommended-key-size-between-symmetric-and -asymmetric-encryption-di）（由于公钥和私钥是相互连接的），而不是对称的。拥有比常用密钥长 10 倍以上的密钥？听起来很腥。或者就像让人们相信我们使用了正确的密钥长度值，因为数字 8192 经常显示为 keysize。只是它不是那个keysize。

总体：没有具体的证据，但我认为它是蛇油。

问题更新后：

我对美国专利制度一无所知，也不想学习任何东西（我不是来自美国，还没有看到任何专利何时有任何好处）。我也不是密码学专家，尽管我确实比一般人知道得更多，甚至有一些学术知识和某种爱好。

每本严肃的密码学书籍/课程/任何东西都会警告您不要使用专有的、未经审查的密码算法，并且有一个很好的理由：很容易犯一些小错误，从而使系统完全不安全。确保它比下一个更安全的唯一方法是进行大量独立审查，并且许多密码学家试图破解它。如果有很多出版物试图为该算法考虑一些东西，但没有真正的成功，那我们就很漂亮了确保这个算法是安全的。就你所说的xAES算法没有这样的评论。这并不是说它不安全。它确实说没有人费心检查它的安全性。它可能和 AES 一样安全，它可能更安全，它可能不如 CAESAR 密码安全，它可能有一个后门，如果你知道它可以读取所有内容。虽然有些未经审查的算法是安全的（AES 在某个时间点是未经审查的算法），但可能性非常大。

我们对它的作者一无所知这一事实无济于事。当然，不能保证一个已知的名字会提出一个好的算法，机会更大，因为那些人​​知道为什么那成千上万的算法不安全。来自没有出版记录的人？来自匿名人士？这可能很好，但这只是一个疯狂的猜测。

TL;DR：如果没有算法，一些熟练的人会花一些时间来破解它，这是一个疯狂的猜测。这就是安全，我们不相信疯狂的猜测。

我们再次得到密钥长度。我无法添加任何新内容。除了它变得更好 - 以前他们声称密钥为 8kbit，现在为 16kbit。好笑，几天和最大使用密钥翻倍？这是一个固定的算法，还是他们只是在我们说话的时候更新它？同样，这种大小的密钥（无论是 8 kbit 还是 16 kbit）对于对称算法来说都是不合理的。比较一下：我的浏览器安装了很多安全证书。这些来自不同的 CA。其中大多数都有 2048 密钥。xAES 密钥大小比第一个数字小 4 倍。我们在这里谈论的是非对称密钥，它往往比相应的对称密钥 (xAES) 大至少 10 倍，它是对称密钥。告诉你：社区认为合理的大小是 x。我们告诉你我们有 32x 并且没有说明为什么我们认为 x 是不够的。现在我们有了 64 倍，而且理由更少。

要么 256 位密钥是安全的，要么拥有 32 倍大的密钥只是浪费资源，要么他们有理由相信它不是，在这种情况下，我希望看到这个原因。更大的密钥大小不会让我们在量子密码学方面走得更远，它是一个完全不同的野兽（想象一下一台机器可以一次尝试所有密钥，就像许多平行宇宙，正确的宇宙成为现实）。

最后，让我们回到他们的报价，稍微分析一下：

xAES 是从 AES 基础上打破的指数级难度级别。

如果您采用 2 倍大的密钥，并假设该算法是安全的，那么您就有 2 倍更难的算法。所以是的，如果你有成倍大的密钥，你有成倍地更难的密码。有点道理。但是我想看看这assume the algorithm is secure部分的证明。

AES 的密钥大小限制 > 265 位，其中开发了 xAES 以克服所有 AES 限制。

我假设 265 位是错字，AES 使用 128、192 或 256 位密钥。

对于 xAES，我们可以有 16kbit 的大小（~2 ⁶⁴倍 AES），

向我解释一下 16384 如何是 2 ⁶⁴倍于 256？16384/256=64。钥匙大了64倍。键空间（可能键的数量）是 2 ⁶⁴倍。这是令人困惑的术语。

就算用量子计算机来破解，也是极其困难的。

往上看。

xAES (extended AES) 是我们的专利加密算法，基于 AES，但具有更大的密钥大小（最大 8192 位），更复杂和更长的多项式（在步骤 MixColumn 中），灵活地使用 Gray-Sbox 或 Sbox（在步骤 SubBytes 中） ,

托马斯·波宁的回答没什么可补充的。但是：什么是更复杂的多项式？多项式很简单。更长的多项式只是更长，而不是更复杂。你可以说 100000 比 100 复杂。

和一些更多的安全修改（盐，密钥扩展等......）。

进行降低安全性的安全性修改非常容易，但很难进行提高安全性的安全性修改。有很多非常微妙的相互联系。您可以使机器中的齿轮以两倍的速度运行，但它会在所有其他齿轮都以先前速度运行的机器中造成严重破坏。

Salt：用于单向函数（“哈希”）的随机数据，通常不是秘密数据。请参阅https://en.wikipedia.org/wiki/Salt_(cryptography)。可以理解为填充，即添加（随机或确定性）数据以填充块或增加消息的“随机性”。不是对称密码的一部分，而是它的使用方式。

密钥扩展：拥有较小密钥并从中生成较大密钥或密钥集的过程，并根据需要具有各种属性。为后续轮次对称密码生成密钥的过程有时被称为（因为我们将密钥扩展为轮次中使用的几个子密钥），所以 AES 已经有了这个。

哦，看，我们使用了一些花哨的加密术语。从不同的背景来看太糟糕了。

看起来他们的首席执行官不知道他在说什么。他的每一个答案都越来越响亮。这里没有积分。

让我引用写 PGP 的人 Phill Zimmermann 的话：

任何认为自己设计了牢不可破的加密方案的人要么是极其罕见的天才，要么是天真和缺乏经验的人。不幸的是，我有时不得不与想要通过添加他们自己设计的加密算法来对 PGP 进行“改进”的潜在密码学家打交道。

我记得 1991 年与美国国家安全局高级密码学家布莱恩·斯诺的一次谈话。他说，他永远不会相信那些没有通过首先花费大量时间来破解密码而“赚到骨头”的人设计的加密算法。这很有意义。我观察到，在密码学的商业世界中，几乎没有人符合这一标准。“是的，”他自信地笑着说，“这让我们在 NSA 的工作变得轻松多了。” 一个不寒而栗的想法。我也没资格。

https://www.philzimmermann.com/EN/essays/SnakeOil.html

让我们看看 Bruce Schneier 的蛇油清单：https ://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil 。在我看来，第 1、3、4、5 和 7 点非常适合。这是 9 分中的 5 分。