認証のためのSRPのより良い代替手段としてPKEを使用できますか？
SRPを正しく理解していれば、その弱点は、検証者をサーバーに送信する際のユーザーの登録中です。
サーバーがユーザーのPubKey（User）を知っていて、ユーザーがサーバーのPubKey（Server）を知っているとしましょう。認証のために、サーバーはPubKey（User）で暗号化されたランダムなシークレットをユーザーに送信します。ユーザーは自分のPrivKey（User）でシークレットを復号化し、PubKey（Server）でシークレットを暗号化して送り返します。その後、サーバーはPrivKey（Server）を使用してシークレットを復号化し、ユーザーに送信されたものと比較します。正しい場合は、ユーザーが認証されます。
それはSRPよりも安全であり、SRPと同じ利点（ユーザーパスワードを保存しない）を提供しますか？
あなたが言う時、
サーバーがユーザーのPubKey（User）を知っていて、ユーザーがサーバーのPubKey（Server）を知っているとしましょう。
sRPが解決する必要があるよりもはるかに簡単な問題を提示しています。簡単に言うと、各当事者が相手の公開鍵をすでに知っている場合は、これで完了です。これにより、すべての相互認証と鍵交換が簡単になります。シークレット（SRPベリファイアなど）を送信する必要はなく、自分の秘密鍵以外のシークレットを保存する必要もありません。
SRPおよびその他のPAKE（パスワードベースの認証済み鍵交換）システムは、通信当事者がすでにお互いの公開鍵を知っている世界では不要になります。
Password-Authenticated Key Exchange メカニズムの要点は、2つのパーティがnotを持っていない場合に、共有シークレットの確立を有効にすることです。共有低エントロピーシークレット（パスワード）よりも優れた相互認証メカニズム。
クライアントがサーバーの公開鍵をかなり確実に知ることができれば、クライアントはその知識を使用してサーバーとの安全なトンネルを開き、そのトンネルでパスワードを送信できます。これは、Webブラウザを使用する一部の人間ユーザーがHTTPSサーバーに接続し、パスワードを入力するときに常に発生します。クライアントは証明書のおかげでサーバーを認証し、SSLを起動するのに十分です。その時点でパスワードはクライアントは期待されるサーバーと通信していることがある程度保証されているため、「現状のまま」送信できます。
したがって、クライアントがサーバーの公開鍵を知っていると想定することから始めれば、SRPを使用する必要はまったくありません。さらに、サーバーがクライアントの公開鍵も知っていると仮定すると、パスワードを使用する必要がなくなります。
パスワード登録を検討してください。その操作の前は、クライアントとサーバーの間に「共有シークレット」はありません。それでも、クライアントはその後、共有シークレットに関する知識を使用してサーバーを認証します。これは、登録時に使用する他の認証方法が必要であることを意味します。これにより、クライアントは、正規のサーバーで設定されていることを確認できます。
SSLを利用したWebインターフェイスを介して登録するクライアントの場合を想像できます（サーバー証明書は、クライアントが本物のサーバーと通信することを確認するために使用されます）。その後、登録されたパスワードが使用されます。証明書の検証を簡単に実行できないクライアントデバイスから。