#### What is The Secure Remote Password (SRP) protocol?

##### February 27, 2018
SRP Secure Remote Password key exchange security cryptography

I have decided to publish materials I wrote for my Computer and Network Security course. It could help someone out there, so why keep it on my hard drive. You can obviously get shorter and straightforward information from following Wikipedia page. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

## So, what is it?

1. Alice sends Bob: M1 = H[H(N) XOR H(g) | H(I) | s | A | B | Kalice]. 2. Bob verifies M1 and sends Alice: M2 = H(A | M1 | Kbob). 3. Alice verifies M2.

In the above description, Alice sends Bob hashed H(N) where N is a large enough safe prime XORed with H(g) and s as a salt. A and B represent a random ephemeral key in order to provide perfect forward secrecy.

## The SRP integrations

Telnet

In order to avoid eavesdropping attacks, SRP has been implemented into Telnet protocol. SRP is used to prevent sending passwords in a plaintext. The SRP improves security by against: Password sniffing attacks, meaning if the attacker listening to the network cannot see the password over the network Dictionary attacks, it would take a huge computational time to even start trying to break the password. SRP requires no certifications, keyrings etc. which makes it simple to understand and implement. SRP Telnet package is realized as a Telnet authentication option. The SRP authentication provides automatic negotiation and in case both sides support SRP, they will try to authenticate. Otherwise, the authentication protocol downgrades to another mechanism that both participants support. The implementation enables users to command with standard commandline commands such as telnet ipaddress instead of using some specific authentication commands such as ssh or kinit. The password will be provided as usual after telnet IPaddress command and the secure session will be established. A simple secure authentication will look like following:

\$ telnet 217.x.x.x
Trying 217.x.x.x...
Connected to 217.x.x.x
Escape character is ’^]’.
[ Trying SRP ... ]
[ Using 1024-bit modulus for ’tjw’ ]
[ SRP authentication successful ]


SSH

SSH is a tool that enables to log in and runs commands on a remote server. SSH employees RSA public key exchange to ensure a secure connection. Even though SSH consider secure it has implementation problems as well as it sends passwords via a secure connection. The latter one leads to the issue when one of the participants is being compromised. The attacker can listen to incoming traffic and capture incoming passwords and try them on different machines. This is where SRP plays a great role to force security even a server is being hacked. Since in SRP one cannot obtain information about the password. As we mentioned SSH uses RSA and it is a patented method, therefore, license required. However, the SRP can provide a secure connection to SSH even without having RSA implementation.

TLS

As SSH, TLS utilizes public-key cryptography. Nowadays, services authenticate users via username and passwords. TLS doesn’t fit well with this idea. Hence, using the SRP protocol provides secure connection using username and password over an insecure network and avoids from an eavesdropper. The SRP is implemented using the standard handshake message exchange protocol. The exchange goes as follows: 1. Client sends “Client Hello” message to the Server 2. The Server sends “Server Hello” and Certificate, Server Key Exchange (N, g, s, B) and “Server Hello Done” message to the client. 3. The Client sends Client Key Exchange (A), [Change cipher spec] and “Finished’ messages to notify finalized exchange. 4. The Server response with “Finished” message. Both sides start exchanging Application Data.

## The SRP implementation and OpenSSL

In this section, we are going to play around OpenSSL SRP support. As we mentioned above discussion one of the important part of the SRP is verifier. First, we start creating the server verifier file running OpenSSL SRP. As we can see from the guide, -gn command is used to provide g and N values which are required for a verifier, just like DH key exchange. Given a large enough g and N and output file name (pwd.srpv), we run following command:

After this, the system asks us password twice, after entering and verifying the password the system generates the verifier. It is worth to mention that pwd.srpv has to exist in the file system. Now, we created the verifier and it is ready to load to the server. Using OpenSSL type *SRP_VBASE* to store and utilize the verifier.
At this point, the server should be configurated to show the client side that it supports SRP cipher suits. We can check available ciphers by running
openssl ciphers -v — grep SRP
In order to show the user available ciphers suits, we include suits in the Client Hello message. It goes without saying that username should also be included when the server response to the authentication request. Now, we can finally test implementation on the client side by requesting:


./ssl_client -v –SRP localhost:2432 Cipher suites: SRP-DSS-AES-256-CBC-SHA SRP-RSA-AES-256-CBC-SHA SRP-AES-256-CBC-SHA SRP-DSS-3DES-EDE-CBC-SHA SRP-RSA-3DES-EDE-CBC-SHA SRP-3DES-EDE-CBC-SHA SRP-DSS-AES-128-CBC-SHA SRP-RSA-AES-128-CBC-SHA SRP-AES-128-CBC-SHA