summaryrefslogtreecommitdiffstats
path: root/security-utils/src/main/java/com/yahoo/security/SealedSharedKey.java
Commit message (Collapse)AuthorAgeFilesLines
* Use explicit `equals` and `hashCode` to use contents of arrays, not just refsTor Brede Vekterli2023-02-141-0/+35
| | | | Also add a friendlier `toString()` that hex dumps the enc/ciphertext fields.
* Add an "interactive" token resealing protocol and basic tooling supportTor Brede Vekterli2023-01-311-5/+14
| | | | | | | | | | | | | | 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.
* Use ChaCha20-Poly1305 instead of AES-GCM for shared key-based cryptoTor Brede Vekterli2023-01-051-8/+8
| | | | | | | | | | | | | | | | | | | | | 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.
* Use Base62 for tokens and Base58 for keysTor Brede Vekterli2022-11-091-7/+11
| | | | | | | | * Base62 minimizes extra size overhead relative to Base64. * Base58 removes ambiguous characters from key encodings. Common for both bases is that they do not emit any characters that interfer with easily selecting them on web pages or in the CLI.
* Encapsulate key identifier in own objectTor Brede Vekterli2022-11-021-22/+8
| | | | Enforces invariants and avoids having to pass raw byte arrays around.
* Let token key IDs be UTF-8 byte strings instead of just an integerTor Brede Vekterli2022-11-011-22/+44
| | | | | | | | | | | | | | This makes key IDs vastly more expressive. Max size is 255 bytes, and UTF-8 form is enforced by checking that the byte sequence can be identity-transformed to and from a string with UTF-8 encoding. In addition, we now protect the integrity of the key ID by supplying it as the AAD parameter to the key sealing and opening operations. Reduce v1 token max length of `enc` part to 255, since this is always an X25519 public key, which is never bigger than 32 bytes (but may be _less_ if the random `BigInteger` is small enough, so we still have to encode the length).
* Use HPKE instead of ECIES for shared single-use keysTor Brede Vekterli2022-10-201-12/+18
| | | | | 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.
* Enforce SHA-256 and AES-CBC for ECIES key wrappingTor Brede Vekterli2022-10-131-3/+11
| | | | | | | 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
* Add utilities for secure one-way single-use key exchange tokens using ECIESTor Brede Vekterli2022-10-111-0/+65
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.