| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Fingerprints are now always derived using the a fixed context
of `Vespa token fingerprint`. Enforcement has been added that a
`TokenDomain` cannot be initialized with a context equal to the
fingerprint context.
This changes the fingerprint outputs from their previous values,
but that's fine since they are not yet in use anywhere.
|
| |
|
| |
|
|
|
|
| |
- Bundle is built with maven-bundle-plugin
|
| |
|
|
|
|
| |
Uses standard fingerprint `hex:hex:hex:...` format
|
| |
|
|
|
|
|
|
|
| |
A token is an arbitrary, opaque (secret) string from which a
fingerprint and audience-specific access-check hashes can be
derived. A CSPRNG-backed token generator that returns random
Base62-encoded tokens (with an optional prefix) is included.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We already have support for the `base` unauthenticated mode, so this
just adds the `auth` mode where the sender's key pair is added to
the ECDH shared key derivation mix. This ensures that a message may
only be successfully opened if the sender was in possession of the
private key (`skS`) corresponding to the expected public key (`pkS`).
|
|\
| |
| |
| |
| | |
vespa-engine/revert-26152-revert-26139-vekterli/add-content-state-api-capability
Reapply: add `vespa.content.state_api` capability"
|
| | |
|
|/
|
|
| |
PeerPolicy" MERGEOK"
|
|\
| |
| | |
Revert "Store original capability (set) names from JSON config in PeerPolicy" MERGEOK
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/add-content-state-api-capability
Add `vespa.content.state_api` capability
|
| |
| |
| |
| | |
Add new capability to existing `vespa.telemetry` capability set.
|
|/
|
|
| |
Add additional helper methods to convert `names <=> capabilities`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also add a friendlier `toString()` that hex dumps the enc/ciphertext fields.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Require 'vespa.rpc.unclassified' by default for all JRT APIs
|
|
|
|
| |
Introduce functional interface ToCapabilitySet to simplify construction of second order capability sets.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements a protocol for delegated access to a shared secret key
of a token whose private key we do not possess. This builds directly
on top of the existing token resealing mechanisms.
The primary benefit of the resealing protocol is that none of the
data exchanged can reveal anything about the underlying secret.
Security note: neither resealing requests nor responses are explicitly
authenticated (this is a property inherited from the sealed shared
key tokens themselves). It is assumed that an attacker can observe
all requests and responses in transit, but cannot modify them.
|
| |
|
| |
|
| |
|
|
|
|
| |
versions" (#25436)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to get around the limitation where AES GCM can only produce
a maximum of 64 GiB of ciphertext for a particular <key, IV> pair before
its security properties break down. ChaCha20-Poly1305 does not have any
practical limitations here.
ChaCha20-Poly1305 uses a 256-bit key whereas the shared key is 128 bits.
A HKDF is used to internally expand the key material to 256 bits.
To let token based decryption be fully backwards compatible, introduce
a token version 2. V1 tokens will be decrypted with AES-GCM 128, while
V2 tokens use ChaCha20-Poly1305.
As a bonus, cryptographic operations will generally be _faster_ after
this cipher change, as we use BouncyCastle ciphers and these do not use
any native AES instructions. ChaCha20-Poly1305 is usually considerably
faster when running without specialized hardware support. An ad-hoc
experiment with a large ciphertext showed a near 70% performance increase
over AES-GCM 128.
|
|
|
|
| |
No functional changes, just bugged me to have used the wrong order.
|
|
|
|
| |
Wrong base was "close enough" that test seemingly worked most of the time...!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resolves two issues:
* `javax.crypto.OutputCipherStream` swallows MAC tag mismatch exceptions
when the stream is closed, which means that corruptions (intentional
or not) are not caught. This is documented behavior, but still very
surprising and a rather questionable default. BC's interchangeable
`CipherOutputStream` throws as expected. To avoid regressions, add an
explicit test that both ciphertext and MAC tag corruptions are propagated.
* The default-provided `AES/GCM/NoPadding` `Cipher` instance will not emit
decrypted plaintext per `update()` chunk, but buffer everything until
`doFinal()` is invoked when the stream is closed. This means that decrypting
very large ciphertexts can blow up memory usage since internal output
buffers are reallocated and increased per iteration...! Instead use an
explicit BC `GCMBlockCipher` which has the expected behavior (and actually
lets cipher streams, well, _stream_). Add an `AeadCipher` abstraction to
avoid leaking BC APIs outside the security module.
|