org.bouncycastle.crypto.agreement.owl (Bouncy Castle Library 1.85 API Specification)
Date: 2026-07-12

# Package org.bouncycastle.crypto.agreement.owl

Support classes for the Owl augmented PAKE (Hao, Bag, Chen, Lopez 2024).

See: Description

- Class Summary
  Class | Description
  --- | ---
  ECSchnorrZKP | Schnorr non-interactive zero-knowledge proof over an elliptic curve, as used in the Owl key exchange.
  OwlAuthenticationFinish | The payload sent by the client during the third pass of an Owl exchange.
  OwlAuthenticationInitiate | The payload sent by the client in the first pass of an Owl exchange.
  OwlAuthenticationServerResponse | The payload sent by the server during the second pass of an Owl exchange.
  OwlClient | A client in the Elliptic Curve Owl key exchange protocol.
  OwlClientRegistration | A client in the Owl key exchange protocol specifically for the user registration phase.
  OwlCurve | A pre-computed elliptic curve over a prime field, in short-Weierstrass form for use during an Owl exchange.
  OwlCurves | Standard pre-computed elliptic curves for use by Owl.
  OwlFinishRegistration | The final payload generated by the `OwlServerRegistration` during the user registration of a Owl exchange.
  OwlInitialRegistration | The payload sent by `OwlClientRegistration`, during the user registration phase of an Owl exchange.
  OwlKeyConfirmation | The payload sent/received during the explicit key confirmation stage of the protocol, Both `OwlClient` and `OwlServer` create and send an instance of this payload to the other.
  OwlServer | A server in the Elliptic Curve Owl key exchange protocol.
  OwlServerRegistration | A server in the Owl key exchange protocol specifically for the user registration phase.
  OwlUtilTest |

## Package org.bouncycastle.crypto.agreement.owl Description

Support classes for the Owl augmented PAKE (Hao, Bag, Chen, Lopez 2024).

Owl is an academic protocol — not (yet) an IETF standard. It extends J-PAKE with explicit user-registration and key-confirmation phases. Users wanting a standardised PAKE should prefer the existing J-PAKE in `org.bouncycastle.crypto.agreement.jpake` / `org.bouncycastle.crypto.agreement.ecjpake`.