@Immutable public final class AesGcmKey extends AeadKey
| Modifier and Type | Class and Description |
|---|---|
static class |
AesGcmKey.Builder
Builder for AesGcmKey.
|
| Modifier and Type | Method and Description |
|---|---|
static AesGcmKey.Builder |
builder() |
boolean |
equalsKey(Key o)
Returns true if the key is guaranteed to be equal to
other. |
Integer |
getIdRequirementOrNull()
Returns null if this key has no id requirement, otherwise the required id.
|
SecretBytes |
getKeyBytes()
Returns the underlying key bytes.
|
Bytes |
getOutputPrefix()
Returns a
Bytes instance which is prefixed to the ciphertext. |
AesGcmParameters |
getParameters()
Returns the parameters of this key.
|
public static AesGcmKey.Builder builder()
public SecretBytes getKeyBytes()
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 AesGcmParameters 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)
Keyother.
Implementations are required to do this in constant time.
Note: this is allowed to return false even if two keys are guaranteed to represent the same function, but are represented differently. For example, a key is allowed to internally store the number of zero-bytes used as padding when a large number is represented as a byte array, and use this in the comparison.
Note: Tink Key objects should typically not override hashCode (because it
could risk leaking key material). Hence, they typically also should not override equals.