可以生成一次性秘密，分佈式網路上的所有節點都可以知道但不能預先計算
我有一個分佈式 P2P 網路。
每天，我希望每個節點都有一個僅在當天有效的秘密，而網路上的每個其他剩餘節點都能夠計算出相同的值。
但是，我不希望任何節點能夠預先計算它；例如，如果是星期一，我不希望任何其他節點能夠在星期四晚上/星期五之前計算秘密
這可能嗎？需要什麼樣的計劃才能有效？
編輯 - 必須在這裡編輯，因為我沒有足夠的聲譽來發表評論，感謝到目前為止的答案，我不可能擁有一個集中式伺服器，因為這會破壞我的模型，我們可以在不需要的情況下實現這一點集中式伺服器，至於我的對手模型，目前我假設一個由 5,000 個節點組成的網路，其中任何高達 49% 的計算能力都可能由攻擊者組成，因此解決方案需要考慮到可支配的電腦能力攻擊者並且無法對其進行中繼可能需要 x 天
編輯 2 - 網路沒有關閉，是的，所有 5,000 多個節點都需要知道秘密，但只能在特定日期計算/分發並在當天有效，我一直在關注網路投票系統，所有節點根據前一天的雜湊計算一個雜湊（就像比特幣雜湊挑戰，其中解決方案是一個隨機數，當添加到另一個雜湊時首先有 x 個零），然後這些的平均值或平均值是用於的秘密接下來的 24 小時
如果你有足夠的頻寬，並且節點之間有良好的通信可靠性，你可以進行多方 Diffie Hellman 密鑰交換。最有效的方法是使用X25519，從而在各方之間共享 256 位機密。然後可以使用它來派生密鑰和其他秘密值。
這也將允許隨時將新節點添加到網路中，它們的公鑰將被添加到池中，並且各方將從目前秘密中計算出新的共享秘密。各方必須就分發和計算秘密所需的時間達成一致，並使用該時間就該秘密生效的設定時間達成一致。如果分發所有公鑰大約需要 5 分鐘，它們可能會提前 7 分鐘開始與網路通信，這樣就不會有一些節點沒有計算秘密的停電期。
如果一個節點信任其他節點代表他們將公鑰轉發給其他節點，則可以大大減少頻寬，如果一個節點信任其他節點從網路的其餘部分計算中間共享密鑰，則可以減少計算量。
也可以使用環形匯流排設計，其中節點傳輸到單個對等點，它們從單個對等點接收，並傳輸它們接收到的池，每次傳輸都會增長 1。最後，所有節點都應該有相同的列表，並且它們可以隨機驗證密鑰池的雜湊與其他節點。如果對等點沒有相同的散列，但確實擁有所有密鑰，則可能是故意為他們提供了不正確的密鑰，並且可以製定程序允許對等點組確定不正確的密鑰在哪裡起源（叛徒追踪）。
最可靠的選擇是讓一個節點將其公鑰發送給網路中的所有對等節點，並從所有其他節點接收密鑰，從而導致 $ n^2-n $ 總密鑰傳輸 $ n $ 對等點，然後與其他幾個對等點驗證列表。
如果所有節點都有一個永久共享的秘密，網路是開放的，並且節點可以不受限制地訪問網際網路，那麼另一個選項是可用的。高熵公共值，例如NIST 隨機信標的輸出，可以使用 HMAC 處理，使用永久機密作為密鑰。生成的輸出將無法在信標之前生成，並且由於生成方法的原因將是加密安全的，只要機密保持與網路隔離。
也可以使用組合方法，在信標發布之前，所有節點使用 Diffie Hellman 商定一個共享密鑰來處理接下來的信標，這給了足夠的時間來驗證每個節點是否具有相同的密鑰。對於具有廣泛分佈（高延遲）或大量節點的開放網路上的節點，這將是最佳選擇。
這個問題在 security.SE 上重新發布這個問題。為了完整起見，我將在這裡重新發布我的答案。
讓我們將問題分解為兩部分：
第一個問題是您想要的東西在外部攻擊者看來是隨機的（即不可預測的），但任何**知情的人都可以計算出來。
這聽起來很像所有節點使用相同種子的加密安全偽隨機數生成器 (CPRNG) 。然後每小時（或每分鐘）你可以在隨機序列中取下一個數字 - 即
current_nonce = cprng.getSequence()[ numberOfHoursSinceLaunch() ];.需要解決的問題是密鑰分配問題——或者在這種情況下，種子分配問題（因為種子充當共享密鑰）。
您可以查看關鍵協議協議：
在密碼學中，密鑰協商協議是一種協議，通過該協議，兩方或多方可以以雙方都影響結果的方式就密鑰達成一致。…在實踐中有用的協議也不會向任何竊聽方透露已商定的密鑰。
或者您可以採用較低技術並讓管理員通過某種安全方法（SSH、USB 密鑰等）將種子放置在每個節點上。或者，您可以設置一個經過客戶端身份驗證的 TLS 網路，其中每個節點都有一個客戶端證書，它們可以用來請求種子。有很多方法可以給這只特殊的貓剝皮。
編輯以回應在crypto.se上的重新發布：
第二個問題是你想要一些系統，即使一個節點擁有所有的種子材料，它也無法計算秘密，直到未來的某個固定時間。這實際上是 Security.SE 和 Crypto.SE 上的一個常見問題。通用名稱是 Time-Capsule Cryptography，在 Time-Lock Puzzle 上。這是有關該主題的著名文章。對此有一些解決方案，但它們都有這樣的味道：“如果你完全執行你的處理器，它們至少需要 X 天才能計算出秘密。我認為這不是你想要的。
這個問題的一個實際解決方案是給每個節點一個客戶端 SSL 證書。擁有一個生成隨機數的主伺服器，然後讓節點使用它們的證書登錄到主伺服器以檢索每日隨機數。