Org.BouncyCastle.Crypto.Agreement.JPake
Namespace with 7 public types
Classes
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).
JPakePrimeOrderGroup
A pre-computed prime order group for use during a J-PAKE exchange.
Typically a Schnorr group is used. In general, J-PAKE can use any prime order group
that is suitable for public key cryptography, including elliptic curve cryptography.
See JPakePrimeOrderGroups for convenient standard groups.
NIST publishes
many groups that can be used for the desired level of security.
JPakePrimeOrderGroups
Standard pre-computed prime order groups for use by J-PAKE.
(J-PAKE can use pre-computed prime order groups, same as DSA and Diffie-Hellman.)
This class contains some convenient constants for use as input for
constructing {@link JPAKEParticipant}s.
The prime order groups below are taken from Sun's JDK JavaDoc (docs/guide/security/CryptoSpec.html#AppB),
and from the prime order groups
published by NIST.
JPakeRound1Payload
The payload sent/received during the first round of a J-PAKE exchange.
Each JPAKEParticipant creates and sends an instance of this payload to
the other. The payload to send should be created via
JPAKEParticipant.CreateRound1PayloadToSend().
Each participant must also validate the payload received from the other.
The received payload should be validated via
JPAKEParticipant.ValidateRound1PayloadReceived(JPakeRound1Payload).
JPakeRound2Payload
The payload sent/received during the second round of a J-PAKE exchange.
Each JPAKEParticipant creates and sends an instance
of this payload to the other JPAKEParticipant.
The payload to send should be created via
JPAKEParticipant#createRound2PayloadToSend()
Each JPAKEParticipant must also validate the payload
received from the other JPAKEParticipant.
The received payload should be validated via
JPAKEParticipant#validateRound2PayloadReceived(JPakeRound2Payload)
JPakeRound3Payload
The payload sent/received during the optional third round of a J-PAKE exchange,
which is for explicit key confirmation.
Each JPAKEParticipant creates and sends an instance
of this payload to the other JPAKEParticipant.
The payload to send should be created via
JPAKEParticipant#createRound3PayloadToSend(BigInteger)
Eeach JPAKEParticipant must also validate the payload
received from the other JPAKEParticipant.
The received payload should be validated via
JPAKEParticipant#validateRound3PayloadReceived(JPakeRound3Payload, BigInteger)
Abstract Classes
JPakeUtilities
Primitives needed for a J-PAKE exchange.
The recommended way to perform a J-PAKE exchange is by using
two JPAKEParticipants. Internally, those participants
call these primitive operations in JPakeUtilities.
The primitives, however, can be used without a JPAKEParticipant if needed.