Package com.google.crypto.tink.internal

Class LegacyProtoKey

java.lang.Object

com.google.crypto.tink.Key

com.google.crypto.tink.internal.LegacyProtoKey

@Immutable
public final class LegacyProtoKey
extends Key

Implements a Key for legacy types where no actual parser is present.

Constructor Summary

Constructors

Constructor	Description
LegacyProtoKey(ProtoKeySerialization serialization, SecretKeyAccess access)	Creates a new LegacyProtoKey object.

Method Summary

Modifier and Type	Method	Description
boolean	equalsKey(Key key)	Returns true if we are sure that the other key is the same.
java.lang.Integer	getIdRequirementOrNull()	Returns null if this key has no id requirement, otherwise the required id.
Bytes	getOutputPrefix()
Parameters	getParameters()	Returns a LegacyParametersNotForCreation object.
ProtoKeySerialization	getSerialization(SecretKeyAccess access)	Returns the protokeyserialization with which this object was created.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

LegacyProtoKey

public LegacyProtoKey(ProtoKeySerialization serialization,
                      @Nullable
                      SecretKeyAccess access)
               throws java.security.GeneralSecurityException

Creates a new LegacyProtoKey object.

Access is required for SYMMETRIC and ASYMMETRIC_PRIVATE key material types.

Throws:

java.security.GeneralSecurityException

Method Detail

equalsKey

public boolean equalsKey(Key key)

Returns true if we are sure that the other key is the same.

Due to the fact that proto key serialization isn't guaranteed to be deterministic, this isn't guaranteed to be true in case two serializations are actually the same. This shouldn't be a problem: the use of key equality is that one can implement keyset equality, which is useful when one wants the guarantee that two keysets are the same (for example, when one changes the source of the keyset from disk to a remotely stored keyset). Since the only thing which can happen is that we falsely return "false", this can then be solved in debugging. (The alternative would be to throw an UnsupportedOperationException while we add the real implementations of keys)

Specified by:

equalsKey in class Key

getIdRequirementOrNull

@Nullable
public java.lang.Integer getIdRequirementOrNull()

Description copied from class: Key

Returns null if this key has no id requirement, otherwise the required id.

Some 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.

Specified by:

getIdRequirementOrNull in class Key

getSerialization

public ProtoKeySerialization getSerialization(@Nullable
                                              SecretKeyAccess access)
                                       throws java.security.GeneralSecurityException

Returns the protokeyserialization with which this object was created.

Access is required for SYMMETRIC and ASYMMETRIC_PRIVATE key material types.

Throws:

java.security.GeneralSecurityException

getParameters

public Parameters getParameters()

Returns a LegacyParametersNotForCreation object.

Note: this is different from the LegacyProtoParameters object which was used to create this key. One cannot use the returned object to create a new key.

Specified by:

getParameters in class Key

getOutputPrefix

public Bytes getOutputPrefix()
                      throws java.security.GeneralSecurityException

Throws:

java.security.GeneralSecurityException