P1363.2 Submission: SRP-4
David Jablon
May 6, 2002
Introduction
This document describes APKAS-SRP4, a password-authenticated key agreement scheme that is a hybrid of
the APKAS-SRP (SRP-3) and APKAS-BSPEKE2 (B-SPEKE) schemes that are defined in the current draft
of [P1363.2], blending benefits of each. It uses an optimized exponential computation similar to that used
in APKAS-SRP, and a prime order password-derived generator as in APKAS-BSPEKE2. Some other
benefits of SRP4 over other methods in [P1363.2] are increased speed over APKAS-BSPEKE2 and
elimination of the "two-for-one" guessing attack and message ordering requirement of APKAS-SRP.
Further definition of and references for SRP-3 and B-SPEKE can be found in [P1363.2], and a related
Internet Draft that discusses SRP-4 is [Jab2002].
Summary of SRP-4
Prior to the steps of secret value derivation, SRP-4 is identical to APKAS-BSPEKE2. Secret value
derivation uses two new secret value derivation primitives, {EC,DL}SVDP-SRP4-{CLIENT,SERVER},
that are similar to the SVDPs currently defined for SRP-3.
A full description of SRP-4 is shown in Appendix A, which is summarized here:
Client
Enrollment:
PVDGP-BSPEKE2
REDP-1
Server
 = salt || pwd || IDs ...
 2 = h()
u = OS2IP( 2) mod r
g1 = h( 2)^k
g1, v  g1, v'
v = g1 ^ u
g1, v'
Key Exchange:
PEPKGP-SPEKE
PEPKGP-SPEKE
s R Zr
w = g1 ^ s
s R Zr
w  w'
w'  w
Abort if w' invalid
SVDP-SRP4-CLIENT
t = hash(w') mod 2
z = w' ^ (s + (t u))
w = g1 ^ s
Abort if w' invalid
b2
SVDP-SRP4-SERVER
t = hash(w) mod 2
z = (w' (v' ^ t)) ^ s
b2
Security considerations
The security properties of SRP4 are a blend of the properties of SRP-3 and B-SPEKE. In particular, SRP-4
appears to eliminate the "two-for-one" attack that is known for SRP-3. As in the SPEKE and B-SPEKE
protocols, it does not appear possible for an attacker to provide a password-entangled key w to either party
that represents a commitment to more than one password at a time, due to the properties of the REDP
P1363.2: SRP-4 Submission
May 6, 2002
1
functions. When used with a suitably random secret key s, each password commitment message w alone
reveals zero information about the password.
A thief who steals the password verification data {g1, v} may attempt to masquerade as the user, either by
performing on-line or off-line guessing. The on-line case is limited by the security parameter b2, as in
SRP-3, and may be further limited by the server counting bad access attempts, as in all APKAS methods.
The ability for the thief enemy to perform off-line attack on the verification data depends on the qualities of
the password relative to the knowledge and capabilities of the thief, as in all APKAS methods.
No formal proofs are proposed in this document.
Summary of Differences from BSPEKE2 and SRP-3
SRP-4 uses the same domain parameters as in APKAS-BSPEKE2, defining a DL or EC Diffie-Hellman
group of prime order r. It also uses a security parameter b2, similar to that used in APKAS-SRP (SRP-3).
The generation of password verification data and the generation and exchange of password-entangled public
keys are identical to that in APKAS-BSPEKE2.
Validity checking of the password-entangled public keys and/or derived shared secrets is similar to that in
APKAS-BSPEKE2, with less flexibility as SRP4 does not use underlying standard DH SVDP primitives.
Unlike SRP-3, there are no requirements on ordering of messages in APKAS-SRP4.
The changes in SRP-4 from SRP-3 are:

Creates generator from the password, instead of using a fixed value.

Removes extra steps associated with the server's password-entangled public key.

Adds password-entanglement for client's public key, removing message order requirement.

Uses prime order EC or DL group, instead of full multiplicative DL group.

Server stores two values, g and v, instead of just v.

Different key validation.
Patent issues
Two patents that are known or appear to be relevant to SRP-4 are US 6,226,383, owned by Phoenix
Technologies, and a pending patent on SRP-3 filed by Stanford University.
References
[P1363.2]
Draft D2002-05-06 of "P1363.2: Standard Specifications for Public Key Cryptography:
Password-based Techniques", P1363 working group, http://grouper.ieee.org/groups/1363/.
[Jab2002]
D. Jablon, "The SPEKE Password-based Key Agreement Methods", draft-jablon-speke01.txt, IETF Internet Draft, April 15, 2002.
P1363.2: SRP-4 Submission
May 6, 2002
2
Appendix A -- SRP4 Primitives and Schemes
6.2.nn SVDP-SRP4-{CLIENT,SERVER}
SVDP-SRP4-{CLIENT,SERVER} is Secret Value Derivation Primitive, SRP4 version for {Client, Server}.
It is based on the work of [Wu98] and [RFC2945] and [===Jablon 2002 submission]. It is defined for use
in either the DL or EC setting. This primitive derives a shared secret value from one party's private key and
another party's password-entangled public key, where the keys have the same domain parameters. This
primitive may be invoked by the scheme APKAS-SRP4-{CLIENT,SERVER}.
Input:
Client only:
 The password-derived value 
Server only:
 The passwordverification data v'
 The Server's own password-entangled public key w
Both parties:
 The party's own private key s
 The other party's password-entangled public key w'
 The security parameter b2
 A hash function Hash with output hLen octets, which may be either SHA-1 (which outputs 20 octets)
[IEEE Std 1363-2000: 14.1.1] or MGF1 parameterized with SHA-1 and hLen (which outputs hLen
octets) [IEEE Std 1363-2000: 14.2.1]
 The domain parameters (including gq and q) associated with s, w, v' and w'
Assumptions: Private key s and domain parameters are valid, DL: w' is in GF(q), EC: w' is a point on the
elliptic curve defined by a and b over GF(q). GCD(k, r) = 1.
Output: The derived shared secret value z, which is a nonzero field element in GF(q).
Operation: The shared secret value z shall be computed by the following or an equivalent sequence of
steps:
1.
2.
3.
4.
5.
If w' is invalid, stop and output "invalid public key".
For Client only: Compute o1 = FE2OSP( w' )
For Server only: Compute o1 = FE2OSP( w )
Compute o2 = Hash(o1)
Compute t1 = OS2IP(o2)
Compute t2 = t1 mod (exp(2, b2))
(See Note 1.)
(Uses w' obtained from Server)
(Uses Server's own w)
For Client only:
6.
Compute an octet string  2 = Hash()
(See Note 2.)
7.
Compute a private key integer u1 = OS2IP( 2) mod r (See Note 2.)
8.
Compute group element z1 = w' ^ (s + u1  t2)
For Server only:
P1363.2: SRP-4 Submission
May 6, 2002
3
9.
Compute group element z1 = (w'  (v' ^ t2)) ^ s
For both parties:
10. Compute z = GE2SVFEP(z1)
11. Output z
NOTE—See additional notes on {EC,DL}APKAS-SRP4 in subclause 9.nn === [[[ === check this ===]]]
NOTE 1—It is generally recomended that Step 1 insure that w' is a valid public key for the domain parameters.
However, such a test may be more than sufficient. It may also be acceptable to insure that the value is in the
appropriate range for computations in the EC/DL setting and that it generates a sufficiently large group. (see
discussion in Std 1363-2000 D.5.3) For example, in a DL setting where all factors of (q-1)/2 are sufficiently large,
such that the only two undesirably small order elements are 1 and q-1, it may be sufficient to insure that w' is in the
range [2, q-2].
NOTE 2—The computation of u1 in steps 6 and 7 must be identical to that in {EC,DL}PVDGP-BSPEKE2. [===
check this ===]. Should probably also add a note to PVDGP-BSPEKE2 pointing to this requirement to match SVDPSRP4-CLIENT.
9.nn {DL,EC}APKAS-SRP4-{CLIENT,SERVER}
{DL,EC}APKAS-SRP4-{CLIENT,SERVER} is {Discrete Logarithm, Elliptic Curve} Augmented
Password-Authenticated Key Agreement Scheme, version {BSPEKE1,BSPEKE2} for {Client, Server}. It
is based on the work of [Wu97], [Jab97], [Jab99] and [Jablon submission 2002].
APKAS-SRP4 derives one or more keys from an optimized password-authenticated Diffie-Hellman
exchange.
NOTE—APKAS-SRP4 is a bilateral commitment scheme, where both parties provide a commitment to the password.
EDITOR’S NOTE—APKAS-SRP4 is a hybrid of APKAS-SRP and APKAS-BSPEKE2.
9.nn.1 Scheme options
{DL,EC}APKAS-SRP4-CLIENT uses an authentication octet string , which is generally derived from a
password, and may also include "salt" and identifying information for one or both parties. The
corresponding {DL,EC}APKAS-SRP4-SERVER uses two password verification data values, g1, v, that
have been created using the appropriate {DL,EC}PVDGP-BSPEKE2 function with input value
corresponding to Client's value of .
Both parties must agree to use a common set of parameters, methods, and related password-based
authentication information as follows:
For CLIENT:
 A password-derived value , ===
For SERVER:
 A password verification data generation primitive PVDGP, which must be either:
 g1 and v', a password verification base element and password-derived public key that were both
computed using {DL,EC}PVDGP-BSPEKE2, with input value , that matches the Client's
initialization value for 
For both parties:
P1363.2: SRP-4 Submission
May 6, 2002
4
 An indication of which setting is to be used, DL or EC
 A set of {DL,EC} domain parameters associated with , g1, and v'.
 A key derivation function, KDF, which may be KDF1
 A security parameter b2
 One or more key derivation parameter octet strings {P1, P2, ...} to be used to derive agreed keys
 Redp, a random element derivation primitive, which may be {DL,EC}REDP-1
 Hash, a hash function, which may be SHA1
NOTE—APKAS-SRP4 and other members of the SPEKE family of schemes require Redp to have the property that, for
any two Redp output values x and y, it is impractical to compute the discrete log base x of y.
9.nn.2 Key agreement operation for CLIENT
1.
2.
3.
4.
5.
Compute  2 = Hash()
Compute g1 = Redp( 2)
Obtain a random secret integer s in the range [1, r - 1]
Compute w using {DL,EC}PEPKGP-BSPEKE( g1, s )
Send w to Server
6.
Receive w' from Server, which was created (as w) in Server's step 2
Compute field element z = {DL,EC}SVDP-SRP4-CLIENT( , s, w', b2 )
If the SVDP function in Step 7 outputs "invalid", output "invalid" and stop.
Compute octet string Z = FE2SVOSP(z)
For each key derivation parameter Pi , derive a shared secret key Ki from the shared secret octet
string Z and Pi using Ki = KDF(Z, Pi).
11. Output derived keys K1, K2, ... Kt
7.
8.
9.
10.
9.nn.3 Key agreement operation for SERVER
1.
2.
3.
Obtain a random secret integer s in the range [1, r - 1]
Compute w using {DL,EC}PEPKGP-BSPEKE( g1, s )
Send w to Client
4.
Receive w' from Client, which was created (as w) in Client's step 4
5.
6.
7.
8.
Compute field element z = {DL,EC}SVDP-SRP4-SERVER( v, w, s, w', b2 )
If the SVDP function in Step 5 outputs "invalid", output "invalid" and stop.
Compute octet string Z = FE2SVOSP(z)
For each key derivation parameter Pi , derive a shared secret key Ki from the shared secret octet
string Z and Pi using Ki = KDF(Z, Pi).
Output derived keys K1, K2, ... Kt
9.
Output: The derived password-authenticated keys {K1, K2, ... Ki}.
No ordering of steps is specified, other than that logically required by the need to compute a value before
using it.
Conformance region recommendations:
 At least one set of valid {DL,EC} domain parameters.
P1363.2: SRP-4 Submission
May 6, 2002
5
 All private keys s valid for each set of domain parameters.
EDITOR’S NOTE—Consider adding idParam, at least for uniformity with other PKAS
P1363.2: SRP-4 Submission
May 6, 2002
6