不依賴於DLP或素數因子分解的Java TLS

我正在使用對Shor算法有抵抗性的加密在Windows上的Java中編寫文件服務器。不依賴於DLP或素數因子分解的Java TLS

我的絆腳石是SSL/TLS。從我可以收集的內容來看，我不能使用標準的java庫，因爲套接字加密使用了依賴於離散對數問題的Diffie-Hellman密鑰交換。

我已經看過Salsa20，一個新的（ISH）流密碼，但安全交換密鑰的問題仍然存在。我也看過cyaSSL，但Java服務提供者不支持Windows，而使用C不是一種選擇。

任何人都可以提供任何方向？

來源

2013-02-13 Saf

標題中的TLS意味着依靠標準化的安全程序。建立對質量控制有抵抗力的方法遠非愚蠢。 – 2013-02-13 18:14:43

@CaptainGiraffe研究後量子密鑰交換是IMO的重要內容。我只是不會使用它。 – CodesInChaos 2013-02-13 18:24:27

@CaptainGiraffe這是一個最後一年的項目（我們做的是一個大型項目而不是論文），所以它更像是一個概念證明，而不是實際將要實際使用的東西。 – Saf 2013-02-13 18:46:05

一般有兩種方法：

使用預共享密鑰

沒有密鑰交換，沒有量子問題。但是現在你需要在帶外分配共享密鑰，所以它可能不能解決問題。
使用量子證明密鑰交換

例如這裏是NTRU一個規範（僅草稿，沒有真正的標準和專利的提防）

但一般不對稱後的量子密碼似乎沒有生產準備。

來源

2013-02-13 18:10:25 CodesInChaos

密鑰大小可能是一個問題。如果Shor正在發揮作用，我們應該期望其他所有的破解方法都是同等先進的。 OTP將是我們唯一的救星。 – 2013-02-13 18:15:36

@CaptainGiraffe沒有跡象表明量子計算機可以用足夠大的密鑰破壞對稱密碼（256位應該沒問題）。量子計算機似乎不太可能提供比使用grover算法減少有效密鑰大小的一半多。 – CodesInChaos 2013-02-13 18:22:17

考慮到量子計算，我很不確定。在熟悉這些算法的同時，我個人的感覺是任何QC問題仍然存在於[Pathological | NP]領域。如果只移動到硬件方面。安全的量子鏈路也只是一個環節。 – 2013-02-13 18:52:45

前景堪憂。

有一些基於難以解決的問題的非對稱密碼系統，不是DLP或保理問題。例如，GGH Cryptosystem基於最接近向量的難題。你會發現有很多抵抗量子密碼的簽名方案，但不是很多的加密系統，而那些確實存在的簽名方案似乎都有一些安全問題。至於將GGH和Lamport Signatures插入Java作爲SSL的提供者，完全是另一個問題。你必須瞭解JCE的工作方式，並做很多工作。

來源

2013-02-13 21:47:06

OP可能不需要非對稱密碼本身。通常文件服務器不是匿名使用的，所以可能有一個密碼或類似的認證方法，可以（可能）利用它來允許你使用對稱密碼。我對OP的建議是爲每個用戶在服務器上存儲一個對稱密鑰。您需要存儲兩個副本，一個未加密，一個使用用戶密碼加密。握手期間，服務器將客戶端的加密版本解密。有沒有發現針對這種方法的攻擊？ – 2013-02-14 03:08:42

不依賴於DLP或素數因子分解的Java TLS

回答

相關問題