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).
JPakeParticipant Class Documentation
Exemplo n.º 1
0
        private ExchangeAfterRound2Creation RunExchangeUntilRound2Creation(JPakeParticipant alice, JPakeParticipant bob)
        {
            JPakeRound1Payload aliceRound1Payload = alice.CreateRound1PayloadToSend();
            JPakeRound1Payload bobRound1Payload = bob.CreateRound1PayloadToSend();

            alice.ValidateRound1PayloadReceived(bobRound1Payload);
            bob.ValidateRound1PayloadReceived(aliceRound1Payload);

            JPakeRound2Payload aliceRound2Payload = alice.CreateRound2PayloadToSend();
            JPakeRound2Payload bobRound2Payload = bob.CreateRound2PayloadToSend();

            return new ExchangeAfterRound2Creation(
                alice,
                aliceRound2Payload,
                bobRound2Payload);
        }
Exemplo n.º 2
0
 public ExchangeAfterRound2Creation(
     JPakeParticipant alice,
     JPakeRound2Payload aliceRound2Payload,
     JPakeRound2Payload bobRound2Payload)
 {
     this.alice = alice;
     this.aliceRound2Payload = aliceRound2Payload;
     this.bobRound2Payload = bobRound2Payload;
 }