非同步使用 Noise 會削弱其安全屬性嗎？

可以在不削弱其安全屬性的情況下非同步使用Noise嗎？

具體來說，有兩個使用者 A 和 B，他們通過在不受信任的伺服器上互相留下消息來進行非同步通信，但他們可能永遠不會同時線上。他們事先知道彼此的公共靜態密鑰，所以KK模式似乎很合適：

KK:
 -> s
 <- s
 ...
 -> e, es, ss
 <- e, ee, se

在我看來，這種模式可以非同步使用而不會削弱它。

A 和 B 最初都將一堆臨時公鑰上傳到伺服器，並在稍後連接時補足供應。

現在 A 想向 B 發送消息：

1. 從伺服器下載 B 的一個臨時密鑰，然後執行第一個握手步驟。
2. 執行第二個握手步驟，生成一個加密的公共臨時密鑰（這樣就完成了握手）。
3. 使用純文字作為有效負載再次執行 Noise，生成加密的傳輸消息。
4. 上傳 B 的純文字臨時密鑰、A 的加密臨時密鑰和加密消息的串聯。

當 B 上線並下載消息時，他們：

1. 如果純文字臨時密鑰不在其未使用密鑰列表中，則丟棄該消息。
2. 執行握手的兩個步驟。
3. 解密加密的消息。

（所以在這種情況下，B 是發起者，A 是響應者。）

我希望這不是題外話。我認為這沒問題，因為我更多地詢問如何使用現有協議，而不是要求對我自己的設計進行密碼分析。

編輯 8 月 27 日

我今天在上述方案中發現了一個陷阱。在規範的第 7.5 節中它說：

…以 K 開頭的模式或我有一個警告，即響應者只能保證它發送的傳輸消息的“弱”前向保密性，直到它收到來自發起者的傳輸消息。在接收到來自發起者的傳輸消息後，響應者確信“強”前向保密。

所以我的方案只會有弱前向保密，這是一種恥辱，因為使用雜訊的全部目的是獲得前向保密。我認為 X3DH（由 Signal 使用）通過簽署預密鑰（初始共享臨時密鑰）來解決這個問題。

線上的 $ \neq $ 同步

是的，Noise 可以在某種非同步設置中使用。

Noise 最初的意思是建立安全通道的“線上”協議，但是這裡的“線上”並不意味著它需要一個“完全同步的網路”，而更像是一個“可靠的通道”，其中數據包將正確進入順序但不一定在給定時間。

適當的握手

在你的情況下，你說：

他們事先知道彼此的公共靜態密鑰

這確實意味著 KK 模式是最合適的模式。現在，您似乎想讓 A 執行所謂的“0-RTT”加密（即在沒有先進行互動式握手的情況下為 B 加密消息/有效負載），這實際上被 Noise 覆蓋：

發起者預先知道響應者的靜態公鑰的模式（即以 K 結尾的模式）允許零 RTT 加密，這意味著發起者可以加密第一個握手有效負載。

因此，使用 0-RTT 和握手實際上已經可以實現您想要實現的目標，KK並且它實際上在規範中，您不需要執行與規範所說的不同的不同步驟。

首先請注意，上面的線...代表各方的“預先知識”。他們通過某種方式（例如通過依賴伺服器）獲取了靜態密鑰，然後開始實際的協議：

1. -> e, es, ss表示 A 正在向 B 發送其臨時密鑰e，並正在es使用其臨時密鑰和 B 的靜態密鑰執行 DH，然後它正在 ss使用自己的靜態密鑰和 B 的靜態密鑰（它具有預先知識）執行另一個 DH。
2. 在執行完這 2 個 DH 之後，A 已經可以計算共享鏈密鑰ck ，它只是 2 個 DH 輸出的雜湊
3. 然後，A 可以使用ck. 請注意，在所有雜訊握手消息中，您都有一個隱式有效負載，其長度可以為零或不為零。（並且在某些條件下是加密的。）
4. 收到後，B 將學習 A 的臨時密鑰並預先知道其靜態密鑰，因此 B 能夠使用e它收到的和自己的靜態密鑰計算與 A 相同的 2 DH，然後使用兩個靜態密鑰，所以 B獲得相同的值ck並且將能夠解密加密的有效載荷。
5. B 生成一個臨時密鑰，計算ee兩個臨時密鑰之間的 DH，最後計算seA 的靜態密鑰和 B 的新臨時密鑰之間的 DH，現在ck狀態再次更新到其“最終”狀態，A 也將能夠在收到 時計算<- e, ee, se。此消息的有效負載也可以使用ck.
6. 請注意，此時最終的共享密鑰ck已被計算為第一個es散列與ss散列與ee散列與散列的散列se。
7. 可以使用生成的密鑰對後續消息進行加密，並根據規范ck增加隨機數（和散列）。ad

我們需要小心，因為規範告訴我們以下內容：

在遠端公鑰（靜態或臨時）和本地靜態密鑰之間執行 DH 後，本地方不得呼叫 ENCRYPT()，除非它還在其本地臨時密鑰和遠端公鑰之間執行了 DH。特別是，這意味著（使用規範符號）：

• 在“ss”令牌之後，發起者不得發送握手有效負載或傳輸有效負載，除非還有“es”令牌。

但是由於我們首先有一個es令牌，然後是ss一個令牌，所以我們可以呼叫ENCRYPT()我們的有效負載。:)

因此，IMO 你不需要做任何不同於規範已經允許和做的事情。只需利用可選的握手有效負載，無需任何更改就可以實現這一點。

替代方案

現在，雖然我在這裡，如果你真的有很強的非同步要求，你可能想看看 Signal 的X3DH用它的一次性預密鑰做什麼，因為非同步是 X3DH 的目標，它基於伺服器像你這樣的設置：

X3DH 專為非同步設置而設計，其中一個使用者（“Bob”）離線但已將一些資訊發佈到伺服器。另一個使用者（“Alice”）想要使用該資訊將加密數據發送給 Bob，並為未來的通信建立一個共享密鑰。

引用自：https://crypto.stackexchange.com/questions/83348