Uses of Package
io.github.mahmoudimus.quic.token

Packages that use io.github.mahmoudimus.quic.token

Package	Description
io.github.mahmoudimus.quic.connection	The sans-I/O QUIC connection and endpoint, ported from quinn-proto: the Connection state machine (handshake, packet assembly and processing, key updates, closing and draining), the Endpoint that routes datagrams and answers with Version Negotiation, Retry and stateless resets, their configurations (TransportConfig, ServerConfig, ClientConfig, EndpointConfig), and the building blocks they are made of: range sets (RangeSet), reassembly of received data (Assembler), buffering of sent data (SendBuffer), streams and flow control (StreamsState), packet number spaces and ACK generation (PacketSpace), loss detection (Recovery), pacing (Pacer), path MTU discovery (MtuDiscovery) and timers (TimerTable).
io.github.mahmoudimus.quic.token	Address validation tokens (RFC 9000 section 8.1), ported from quinn-proto's token.rs and bloom_token_log.rs: Retry and NEW_TOKEN tokens sealed with AES-256-GCM under a key the server holds (TokenKey), their validation with expiry and address binding (TokenValidator), and a bounded replay log (BloomTokenLog); on the client, where NEW_TOKEN tokens wait for the next connection (TokenStore, TokenMemoryCache).

Classes in io.github.mahmoudimus.quic.token used by io.github.mahmoudimus.quic.connection

Class	Description
TokenKey	The server's secret for sealing address validation tokens, as quinn does it: an HKDF-SHA256 pseudorandom key from a master key, from which each token derives a one-time AES-256-GCM key using its random nonce as the HKDF info.
TokenStore	Where a client keeps the address validation tokens servers send in NEW_TOKEN frames (RFC 9000 section 8.1.3), by server name, to present in the first Initial of a later connection so the server can skip its Retry round trip.

Classes in io.github.mahmoudimus.quic.token used by io.github.mahmoudimus.quic.token

Class	Description
BloomTokenLog	A TokenLog of bounded memory.
IncomingToken	What the token in a client's first Initial packet establishes.
Token	An address validation token: a payload and a random nonce.
TokenKey	The server's secret for sealing address validation tokens, as quinn does it: an HKDF-SHA256 pseudorandom key from a master key, from which each token derives a one-time AES-256-GCM key using its random nonce as the HKDF info.
TokenLog	Limits the reuse of NEW_TOKEN tokens, which attackers could replay to use the server as an amplifier (RFC 9000 section 8.1.4).
TokenPayload	What an address validation token says, encrypted so that only the server can read it.
TokenStore	Where a client keeps the address validation tokens servers send in NEW_TOKEN frames (RFC 9000 section 8.1.3), by server name, to present in the first Initial of a later connection so the server can skip its Retry round trip.