是否可以生成隨機位作為私鑰導入，然後推導出他的公鑰？
是否可以生成隨機位（或我們決定的任何位）作為私鑰導入，然後扣除他的公鑰？
理想情況下，使用受支持的 Javascript WebCrypto 算法（ECDSA、RSASSA-PKCS1-v1.5 或 RSA-PSS），或者如果不可能手動實現任何其他算法。
編輯（在否決後）：
我不理解反對票，如果有人想向我表達他的感受……我們在加密部分，我在問一個嚴肅的問題，我相信私鑰不能是隨機的，應該尊重某種數學曲線，所以，不能是我們想要的。對不起，如果這個問題是一個新手問題，但我相信 StackExchange 的好人會問這個問題，不是嗎？
對於更詳細的解釋，主要目標是根據使用者的密碼推導生成私鑰，創建（推導出）公鑰以發送到伺服器。然後進行身份驗證，伺服器發送一個質詢，客戶端重新創建私鑰並簽署質詢，然後伺服器可以確定它是正確的密碼。如果伺服器數據庫洩露，則無法暴力破解密碼。我已經在另一個問題中解釋過了。
你的想法會起作用（大部分）。
每個公鑰算法都包含一個公鑰/私鑰生成算法；該算法採用隨機位源，並生成公鑰/私鑰對。該算法是確定性的，因此再次使用這些相同的隨機位將產生相同的公鑰/私鑰對。因此，如果您獲取密碼，並將其作為種子提供給 RNG（或密鑰派生函式），您可以使用該輸出來生成您的公鑰/私鑰，您就可以開始了。
我的意見：如果你採用這種方法，我不會使用 RSA；它的公鑰/私鑰生成算法需要可變的時間；我會使用 ECDSA（DSA 也可以），如果速度太快，請使用scrypt或argon-2擴展密碼（兩者都設計為慢速密碼散列函式，並具有使密碼散列過程佔用的參數適當的時間長度）。
但是，整體協議存在問題；如果有中間人（即有人坐在有效客戶端和有效伺服器之間），他可以將挑戰從伺服器傳遞給客戶端，並將來自客戶端的響應傳遞給伺服器；此時，客戶端已通過身份驗證，並且中間人仍在偵聽（因此在對話的後期，能夠在不被發現的情況下修改流量）。
我的建議是不要使用這種方法，而是使用類似SRP的方法；這是一種身份驗證協議，它還為伺服器數據庫洩漏（您正在尋找）提供保護，此外，有效的客戶端和伺服器在最後生成相同的密鑰（中間人不會知道）; 此密鑰可用於保護（加密和完整性檢查）以後的流量，保護它免受中間人的影響。