不依赖DLP或素因子分解的Java TLS

我正在用Java在Windows上编写一个文件服务器，使用的加密技术可以抵抗Shor的算法

我的绊脚石是SSL/TLS。据我所知，我不能使用标准java库，因为套接字加密使用Diffie-Hellman密钥交换，这依赖于离散对数问题

我已经研究了Salsa20，一种新的（ish）流密码，但是安全交换密钥的问题仍然存在。我也看过cyaSSL，但是Java服务提供商不支持windows，使用C也不是一个选项

---

有人能提供方向吗

通常有两种方法：

使用预共享密钥

没有密钥交换，没有量子问题。但是现在您需要将共享密钥分发到带外，因此它可能无法解决问题

使用量子验证密钥交换

例如，这里有一个规范（只有草案，没有真正的标准，还要注意专利）

但一般来说，非对称后量子密码似乎并没有做好生产准备

前景黯淡

有一些非对称密码系统是基于棘手的问题，而不是DLP或因子分解问题。例如，最接近向量的困难问题就是这个问题的基础。你会发现有很多签名方案对量子密码学有抵抗力，但没有很多加密系统，而且确实存在的签名方案似乎都有一些安全问题

---

至于将GGH和Lamport签名作为SSL的提供者插入Java，这完全是另一个问题。您必须了解JCE是如何工作的，并做大量的腿部工作。

TLS在标题中意味着依赖标准化的安全程序。以我的拙见，创建抗QC的方法远不是愚蠢的。@CaptainGiraffe研究后量子密钥交换在我看来很重要。我只是还不会使用它。@CaptainGiraffe这是一个大学最后一年的项目（我们做了一个大项目而不是一篇论文）因此，它更像是一个概念证明，而不是实际使用的东西。您真的需要使用SSL/TLS吗？除非这是规范的一部分，否则对于您的问题来说，这听起来像是矫枉过正。相反，只需对普通TCP连接进行加密。我不是密码机，所以这可能是个坏主意，但是考虑在文件服务器上为每个用户（用用户密码加密）存储一个对称密钥。然后，您可以将加密密钥传递给客户端，客户端可以使用用户输入的密码对其进行解密。密钥大小可能是一个问题。如果肖尔在发挥作用，我们应该期待每一个其他破解方法同样先进。OTP将是我们唯一的救世主。@长颈鹿船长没有迹象表明量子计算机可以用足够大的密钥（256位就可以了）破解对称密码。量子计算机似乎不太可能通过使用grover的算法将有效密钥大小减半以上。我很不确定是否考虑量子计算。虽然熟悉这些算法，但我个人的感觉是，任何质量控制问题仍然存在于[physical | NP]领域。如果只移动到硬件端。此外，安全量子链路只是一个链路。@超过256位的长颈鹿船长密钥在物理上根本不可能使用蛮力（例如，仅通过所有2^256个值运行计数器需要超过超新星的全部能量输出）。各种密码分析方法通常可以通过额外的回合来停止，并且很少实际可行。对称加密就可以了。安全创新给了我使用Ntru的学生许可证，并向我发送了我需要的文件，这是C代码，因此需要一些黑客攻击，但至少有一个解决方案。OP可能不需要非对称加密。通常，文件服务器不是匿名使用的，因此可能有一种密码或类似的身份验证方法，可以（也许）利用它来允许您使用对称加密。我建议OP在服务器上为每个用户存储一个对称密钥。您需要存储两个副本，一个未加密，另一个使用用户密码加密。在握手过程中，服务器发送加密版本供客户端解密。是否存在针对这种方法的已知攻击？