@Alpha @Immutable public final class ChaCha20Poly1305Key extends AeadKey
ChaCha20-Poly1305 allows no parameters; hence the main part here is really just the keys.
However, Tink allows prefixing every ciphertext with an ID-dependent prefix, see ChaCha20Poly1305Parameters.Variant.
| Modifier and Type | Method and Description |
|---|---|
static ChaCha20Poly1305Key |
create(ChaCha20Poly1305Parameters.Variant variant,
SecretBytes secretBytes,
Integer idRequirement) |
static ChaCha20Poly1305Key |
create(SecretBytes secretBytes) |
boolean |
equalsKey(Key o)
Returns true if the key is equal to the passed in key.
|
Integer |
getIdRequirementOrNull()
Returns null if this key has no id requirement, otherwise the required id.
|
SecretBytes |
getKeyBytes() |
Bytes |
getOutputPrefix()
Returns a
Bytes instance which is prefixed to the ciphertext. |
ChaCha20Poly1305Parameters |
getParameters()
Returns the parameters of this key.
|
public Bytes getOutputPrefix()
AeadKeyBytes instance which is prefixed to the ciphertext.
In order to make key rotation more efficient, Tink allows every Aead key to be prefixed with a sequence of bytes. When decrypting data, only keys with matching prefix have to be tried.
Note that a priori, the output prefix may not be unique in a keyset (i.e., different keys in a keyset may have the same prefix or, one prefix may be a prefix of the other). To avoid this, built in Tink keys use the convention that the prefix is either '0x00' or '0x01'. See the Tink keys for details.
getOutputPrefix in class AeadKeypublic static ChaCha20Poly1305Key create(SecretBytes secretBytes) throws GeneralSecurityException
GeneralSecurityExceptionpublic static ChaCha20Poly1305Key create(ChaCha20Poly1305Parameters.Variant variant, SecretBytes secretBytes, @Nullable Integer idRequirement) throws GeneralSecurityException
GeneralSecurityExceptionpublic SecretBytes getKeyBytes()
public ChaCha20Poly1305Parameters getParameters()
AeadKeygetParameters in class AeadKey@Nullable public Integer getIdRequirementOrNull()
KeySome keys, when they are in a keyset, are required to have a certain ID to work properly.
This comes from the fact that Tink in some cases prefixes ciphertexts or signatures with the
string 0x01<id>, where the ID is encoded in big endian (see the documentation of the
key type for details), in which case the key requires a certain ID.
getIdRequirementOrNull in class Keypublic boolean equalsKey(Key o)
KeyImplementations are required to do this in constant time.
Note: Tink Key objects should typically not override hashCode (because it
could risk leaking key material). Hence, they typically also should not override equals.