| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Also use AES-128 instead of AES-256 for the one-time key since the underlying
HPKE AEAD cipher protecting the key itself is AES-128.
|
|
|
|
|
|
|
| |
Avoids the need to pass the full key pair when opening a sealed piece
of ciphertext, since we can just extract the public key on-demand.
Uses BouncyCastle X25519 utils under the hood.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HPKE is a hybrid encryption scheme that builds around three primitives:
* A key encapsulation mechanism (KEM)
* A key derivation function (KDF)
* An "authenticated encryption with associated data" (AEAD) algorithm
The 3-tuple (KEM, KDF, AEAD) is known as the HPKE _ciphersuite_.
This implementation has certain (intentional) limitations:
* Only the `DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, AES-128-GCM`
ciphersuite is implemented. This is expected to be a good default
choice for any internal use of this class.
* Only the "base mode" (unauthenticated sender) is supported, i.e.
no PSK support and no secret exporting. This implementation is
only expected to be used for anonymous one-way encryption.
* The API only offers single-shot encryption to keep anyone from
being tempted to use it to build their own multi-message protocol
on top. This entirely avoids the risk of nonce reuse caused by
accidentally repeating sequence numbers.
**Deprecation notice:** once BouncyCastle (or the Java crypto API)
supports HPKE, this particular implementation can safely be deprecated
and sent off to live on a farm.
|
|
|
|
|
| |
Lets arrays be compared without leaking information about their
contents caused by early exits etc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HKDF is initialized ("extracted") from a (non-secret) salt and a secret key.
From this, any number of secret keys can be derived ("expanded") deterministically.
When multiple keys are to be derived from the same initial keying/salting material,
each separate key should use a distinct "context". This ensures that there exists
a domain separation between the keys. Using the same context as another key on a
HKDF initialized with the same salt+key results in the exact same derived key
material as that key.
This implementation only offers HMAC-SHA256-based key derivation.
Tested with all HMAC-SHA256 test vectors in RFC-5869, with added edge case tests.
Analogous to BouncyCastle's `HKDFBytesGenerator`, but with a simpler API that
tries to be very explicit in its operation, as well as fully thread safe due to
not storing intermediate calculations in member fields.
|
|
|
|
|
|
|
| |
For some reason requires passing in and keeping an explicit IV. Not sure
why this is the case, since symmetric keys used in the context of a hybrid
crypto scheme are generally derived via a KDF from the shared secret.
This stuff is practically entirely undocumented... :I
|
|\
| |
| | |
Upgrade BouncyCastle to 1.72 [run-systemtest]
|
| |
| |
| |
| | |
Migrate to artifact names used by 1.71+
|
| |
| |
| |
| |
| | |
* Make `SecureRandom` a shared static field
* Just take in `PrivateKey` instead of `KeyPair` for key unsealing
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lets a sender generate a random, single-use symmetric key and securely
share this with a receiver, with the sender only knowing the public
key of the receiver. The shared key is exchanged via an opaque token
that can only be decoded by having the private key corresponding to
the public key used for encoding it.
This is implemented using ECIES, a hybrid encryption scheme using
Elliptic Curve Diffie-Hellman (ECDH) for ephemeral key exchange combined
with a symmetric cipher using the ephemeral key for actual plaintext
encryption/decryption.
In addition to the key exchange itself, utilities for creating
encryption and decryption ciphers for AES-GCM-256 from the shared keys
are included.
**Security note**: since the key is intended to be used for producing a
single piece of ciphertext, a fixed Initialization Vector (IV) is used.
The key MUST NOT be used to produce more than one ciphertext, lest the
entire security model breaks down entirely.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Bound key-value pairs from SSL handshake session are now copied to the final SSL session object.
This simplifies the dataflow - not need to retrieve the instance right after our custom trust manager is invoked.
|
| |
|
|
|
|
|
| |
Add peerSpec to Target/Connection. Always provide ConnectionAuthContext.
Add helper for creating default, all-granting ConnectionAuthContext.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Facilitate improved encapsulation of Vespa mTLS related classes
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Interpret empty AuthorizedPeers as granting all capabilities unconditionally.
Assume AuthorizedPeers as always present.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Introduce new ConnectionAuthContext as replacement for AuthorizationResult/SecurityContext.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|