通過 TLS 發送的數據的不可否認性
Andy 將通過 TLS 連接到伺服器 Selma。之後，安迪希望能夠發布所有內容（密文、明文、他所有的密鑰）並向中介證明他通過 TLS 向 Selma 發送了哪些數據；或證明 Selma 通過 TLS 發送給他的數據。有什麼辦法可以做到這一點嗎？
更具體地說：我們需要某種方式，第三方可以查看安迪發布的資訊並說服他們自己沒有撒謊。Selma 是一個現有的、未經修改的 TLS 伺服器；它不能被修改。假設 Selma 是可信的：即第三方願意相信 Selma 沒有試圖愚弄他們，也沒有與 Andy 勾結。但是，第三方不信任 Andy：他們需要一種方法來驗證 Andy 沒有謊報通過 TLS 連接發送/接收的數據。如果這有助於實現這一目標，安迪可以使用 TLS 選項和特性以及隨機值/隨機數的一些巧妙/偷偷摸摸/奇怪的組合。可以使用客戶端證書。Andy 願意在發布他的數據時透露他的私鑰和所有會話密鑰。
有沒有辦法實現這些目標並使 Andy 能夠證明通過與 Selma 的 TLS 連接發送/接收了哪些數據？
我確實知道安迪以後可能會證明他確實打開了與 Selma 的 TLS 連接（因為 TLS 協議有 Selma 簽名或解密某些東西）。但這對我的目的來說還不夠；我希望 Andy 能夠展示通過 TLS 連接發送了哪些數據。僅僅證明 Andy 和 Selma 之間的 TLS 連接在某個時間點存在是不夠的。
我的分析：我看不到實現這個目標的方法。看來我們需要一種方法讓 Selma 簽署依賴於應用程序數據的東西。但是，在 TLS 協議中，Selma 簽名的內容似乎與應用程序數據無關。Finished 消息具有所有握手消息內容的執行雜湊，但它似乎不包含任何應用程序數據，並且無論如何它都沒有簽名。我查看了多個密鑰交換以及會話重新協商和錯誤啟動等功能，但仍然找不到解決方法。我已經看到SSL 數據包的跟踪是否提供數據真實性的證明？，如果安迪和塞爾瑪不做任何奇怪的事情，答案是否定的。
換句話說：如果我的問題的答案是“做不到”，那就意味著數據是完全可以否認的：不管安迪做什麼，安迪總是可以改變主意，然後拿出一個假的成績單和謊言關於發送/接收的數據。另一方面，如果數據在某些情況下不可否認，那麼這可能意味著對我的問題的某種“是”回答。
在 TLS 允許伺服器發送應用程序數據之前，客戶端只有兩條消息 ；ClientHello 和另一個，按此順序。 此外，客戶端不會
在 ClientHello 和來自客戶端的其他消息之間保留任何秘密隨機性。
因此，第三方可以使用以下策略來嘗試打破可否認性：
在連接開始之前，第三方生成ClientHello，選擇一個PRF密鑰，並給Andy那個ClientHello和混淆程式碼實現
$$ apply the PRF to the server’s initial response, and use that output and randomness to generate the next client-to-server message $$.
Andy 從第三方發送 ClientHello，將混淆程式碼應用於 Selma 的響應，將該程式碼的輸出發送到伺服器，從 Selma 獲取經過身份驗證的應用程序數據，
然後將 Selma 到 Andy 的兩條消息都發送給第三方。
由於第三方知道 PRF 密鑰，第三方可以
驗證和解密來自 Selma 的所謂的經過身份驗證的應用程序數據。
通過這個答案的前兩句話和待混淆程式碼的 PRF 的安全性
以及 TLS 的 MAC 是無狀態的這一事實，無論級別如何，僅僅倒帶是
不夠的，所以如果混淆是 Virtual Black Box 那麼，沒有塞爾瑪的合作，
Andy 無法讓第三方接受除
Selma 實際發送的應用程序數據之外的任何應用程序數據，即使 Andy 對第三方具有 oracle 訪問權限。
當然，Virtual Black Box 混淆一般是不可能的，但除了 Level 4+ 和更高級別的 +s 暗示了一個安全的簽名與消息恢復方案，其中 TLS 的對稱部分是簽名算法，我不是意識到不應該有一個足夠好的混淆方案來混淆這個答案中的相關內容的任何論點。
（另一方面，我對這種混淆方案可能是什麼樣子也知之甚少。） 級別 1：
如果混淆程式碼將 ClientHello 消息作為另一個輸入（而不是第三方給 Andy 一個特定的 ClientHello 消息）並使用完全呼叫者隨機化的PRF，那麼對於誠實的第三方可能的所有混淆程序-party 來生成
（但由伺服器選擇），伺服器將安迪的前兩條消息（後者通過混淆程序生成）與普通客戶端的前兩條消息區分開來的能力為零。（呼叫者可隨機化 PRF 的基於weakPRP的構造
導致完美的呼叫者隨機性屬性無條件地保持。）
級別 2：
級別 1 程式碼可以擴展為對來自客戶端的應用程序數據進行身份驗證，並
從伺服器對經過身份驗證的應用程序數據進行解密。在這種情況下，在混淆程式碼的相同 假設下，伺服器區分 Andy 和普通客戶端
的唯一方法 是發送無效的據稱經過身份驗證的應用程序數據。
級別 3：
級別 2 程式碼可以擴展到
$$ come close-enough to verifying the
authentincrypted Application Data from the server $$即，在混淆程式碼的相同假設下
，它會很難或$$ information-theoretically impossible $$
讓伺服器將 Andy 與普通客戶端區分開來。 第 4
級：可以修改第 3 級程式碼，以
與普通客戶端相同的方式驗證來自伺服器的經過身份驗證的應用程序數據，因此在對混淆程式碼的相同假設下，
伺服器將零能力區分安迪和普通客戶。
一個級別的+：
可能有
$$ a specific simply-efficient obfuscation scheme achieving the Level $$為此
，安迪不可能有不可忽視的機會欺騙第三方。
（而不是$$ the scheme just being fast-enough to break deniablility $$
或者$$ there just not being an efficient way to reliably simulate $$) 級別 5：
級別 4 程式碼可以修改為輸出
$$ signatures from a standard signature scheme $$關於結構編碼$$ the relevant parts of the protocol’s first three messages $$和$$ the plaintext Application transcript $$. 在這種情況下，第三方只需要安全地生成
簽名驗證密鑰和混淆程式碼，而不是檢查安迪的聲明。 第 6 級：
在第 5 級甚至可能存在破壞可否認性的 規範
“混淆程式碼”， 在這種情況下，甚至不需要指定第三方
- 每個人都可以檢查而無需信任任何人。