I am a student taking cryptography this semester. I was just wondering why can't we use this simple protocol?
Alice → Open Connection → Bob
Alice ← Cert$_b$ ← Bob
Alice → {K$_{AB}$}$_{Bob}$ → Bob
Assume bob is the server and we're only interested in one way authentication.
Is there anything wrong with it in terms of security and performance?
Bob needs proof that Alice is authentic: A-Open Connection-Cert partial random key->B Both keys combine to form an access key.
Standard one-way authentication protocol only requires submitting a correct password once, in order to gain access and control. By randomizing part of Alice's password, significantly reduces the likelihood of her password becoming victim of replay attacks and man-in-the-middle-attacks, just to name a few. [Random Assymetric] Bob's server has been preset for random variations of Alice's hash value
Technically speaking, there is nothing wrong with your suggested one-way authentication protocol. However, the security function of your protocol can be increased by preconfiguring Bob's server with random hash variations of Alice's password for added security. Best of luck with your protocol
Security wise, it's susceptible to a replay attack since no nonce or timestamp is used. Alice is also not authenticated, only Bob is.
As for performance, since there is no preshared secret, one pki operation is needed. So it's quite efficient as it's only two pass.
For one-way authentication (where Bob is the server and Alice the client), I would rather do something like this:
Alice → Open Connection → Bob
Alice ← $R$ ← Bob
Alice → $K_{A-B} (R)$ → Bob
By using a “once-in-a-lifetime” value $R$, and then checking the returned value, $K_{A-B} (R)$, Bob can be sure that both Alice is who she says she is (since she knows the secret key value needed to encrypt $R$) and is "live" (since she has encrypted the nonce, $R$, that Bob just created).
Now…
Your description looks pretty similar but it notes a $Cert_b$ which I interpret to be a certificate. A certificate does not represent a “once-in-a-lifetime” value. In your case, Bob would not be sure if Alice is "live" because the certificate data could have been collected/intercepted at an earlier time… potentially by Eve instead of Alice. As a result, authentication would fail secure verification in your protocol description. In the end, you're facing the possibility of crashing into a replay attack by Eve when doing it your way.
