<PackageReference Include="BouncyCastle.Cryptography" Version="2.1.0" />

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.