Org.BouncyCastle.Crypto.Agreement.JPake.JPakeParticipant
A participant in a Password Authenticated Key Exchange by Juggling (J-PAKE) exchange.
The J-PAKE exchange is defined by Feng Hao and Peter Ryan in the paper
"Password Authenticated Key Exchange by Juggling, 2008."
The J-PAKE protocol is symmetric.
There is no notion of a client or server, but rather just two participants.
An instance of JPakeParticipant represents one participant, and
is the primary interface for executing the exchange.
To execute an exchange, construct a JPakeParticipant on each end,
and call the following 7 methods
(once and only once, in the given order, for each participant, sending messages between them as described):
CreateRound1PayloadToSend() - and send the payload to the other participant
ValidateRound1PayloadReceived(JPakeRound1Payload) - use the payload received from the other participant
CreateRound2PayloadToSend() - and send the payload to the other participant
ValidateRound2PayloadReceived(JPakeRound2Payload) - use the payload received from the other participant
CalculateKeyingMaterial()
CreateRound3PayloadToSend(BigInteger) - and send the payload to the other participant
ValidateRound3PayloadReceived(JPakeRound3Payload, BigInteger) - use the payload received from the other participant
Each side should derive a session key from the keying material returned by CalculateKeyingMaterial().
The caller is responsible for deriving the session key using a secure key derivation function (KDF).
Round 3 is an optional key confirmation process.
If you do not execute round 3, then there is no assurance that both participants are using the same key.
(i.e. if the participants used different passwords, then their session keys will differ.)
If the round 3 validation succeeds, then the keys are guaranteed to be the same on both sides.
The symmetric design can easily support the asymmetric cases when one party initiates the communication.
e.g. Sometimes the round1 payload and round2 payload may be sent in one pass.
Also, in some cases, the key confirmation payload can be sent together with the round2 payload.
These are the trivial techniques to optimize the communication.
The key confirmation process is implemented as specified in
NIST SP 800-56A Revision 1,
Section 8.2 Unilateral Key Confirmation for Key Agreement Schemes.
This class is stateful and NOT threadsafe.
Each instance should only be used for ONE complete J-PAKE exchange
(i.e. a new JPakeParticipant should be constructed for each new J-PAKE exchange).
namespace Org.BouncyCastle.Crypto.Agreement.JPake
{
public class JPakeParticipant
{
public static readonly int STATE_INITIALIZED;
public static readonly int STATE_ROUND_1_CREATED;
public static readonly int STATE_ROUND_1_VALIDATED;
public static readonly int STATE_ROUND_2_CREATED;
public static readonly int STATE_ROUND_2_VALIDATED;
public static readonly int STATE_KEY_CALCULATED;
public static readonly int STATE_ROUND_3_CREATED;
public static readonly int STATE_ROUND_3_VALIDATED;
public virtual int State { get; }
public JPakeParticipant(string participantId, char[] password);
public JPakeParticipant(string participantId, char[] password, JPakePrimeOrderGroup group);
public JPakeParticipant(string participantId, char[] password, JPakePrimeOrderGroup group, IDigest digest, SecureRandom random);
public virtual JPakeRound1Payload CreateRound1PayloadToSend();
public virtual void ValidateRound1PayloadReceived(JPakeRound1Payload round1PayloadReceived);
public virtual JPakeRound2Payload CreateRound2PayloadToSend();
public virtual void ValidateRound2PayloadReceived(JPakeRound2Payload round2PayloadReceived);
public virtual BigInteger CalculateKeyingMaterial();
public virtual JPakeRound3Payload CreateRound3PayloadToSend(BigInteger keyingMaterial);
public virtual void ValidateRound3PayloadReceived(JPakeRound3Payload round3PayloadReceived, BigInteger keyingMaterial);
}
}