Ed25519
擁有證明。x25519 + ed25519
有客戶端和伺服器。
客戶端之前已將 x25519 和 ed25519 的公鑰發送到伺服器。現在需要證明它有他們的私鑰。
我在 Digital Ocean 對 ssh 協議的描述中找到了類似的解決方案：https ://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process#authenticating-the-user’s-access-到伺服器
並在 SSH 身份驗證協議 RFC 中：https ://www.rfc-editor.org/rfc/rfc4252#section-7
總體方案：
- 伺服器生成一些“隨機數”。使用客戶端的 x25519 公鑰對其進行加密並發送給客戶端。
- 客戶端使用相應的 x25519 私鑰解密“nonce”。使用 ed25519 私鑰對其進行簽名，並發送帶有簽名的原始數據。
- 伺服器檢查數據是否等於在 (1) 中發送的數據。並核對簽名。所有權證明已完成。
我有兩個問題：
- 這個方案正確嗎？我應該查看/閱讀什麼以使其正確？
- 在 Digital Ocean 的文章中，您可以發現客戶端不會將原始數據發送回伺服器，而是獲取其中的 md5 並僅發送 md5。為什麼這樣 ？那個操作有什麼意義？我應該這樣做嗎？
- 這個方案正確嗎？我應該查看/閱讀什麼以使其正確？
一個明顯的問題是客戶端願意使用其私鑰解密任意密文。因此，如果它將私鑰用於任何其他目的，那麼它是不安全的。
- 在 Digital Ocean 的文章中，您可以發現客戶端不會將原始數據發送回伺服器，而是獲取其中的 md5 並僅發送 md5。為什麼這樣 ？
嗯，這是為了防止有人將客戶端用作解密Oracle；他們仍然可以將其用作“解密和 MD5”Oracle，但這並沒有那麼糟糕。
就個人而言，我會做出三個改變：
- 將 MD5 替換為現代散列（例如 SHA-256） - 雖然 MD5 在這種用途中可能是完全安全的，但它已經顯示出足夠多的弱點，因此轉向清晰可能是更明智的選擇。
- 我會用隨機散列替換確定性散列。也就是說，我會讓客戶選擇一個隨機字元串“r”，然後返回這對 $ r, SHA256( r || decryption ) $ . 這樣，客戶端也不能用作“解密和 SHA256”預言機。
- 在解密失敗時，我會確保我會選擇一個隨機解密，並返回對 $ r, SHA256( r || random ) $ - 沒有理由給人們一個“這是一個有效的密文”Oracle。
實際上，就我個人而言，我可能會用 Schnorr 知識證明來替換整個事情，但我寧願假設你不想批量替換所有東西……