If a site has business rules that encrypt sensitive data but delete it after a short and fixed period—for example, at the end of the month, quarter, or even a year—using the HMAC will result in just slightly faster processing of transactions on SAKA and the use of less storage—SAKA will have no need to execute either the tokenization code on the appliance or to store any PSNs. However, the performance and storage benefits are very marginal and should not be relied upon to make a significant difference.

Using HMACs as tokens works best only when businesses do not expect to query SAKA past the end of the year—the maximum key-duration of the DHK—unless they coordinate the change in HMAC values after execution of the HMAC key rotation job with their applications. At the start of a new calendar year, SAKA will use a new DHK to calculate the HMAC of all new encryption requests. Thus, a credit card number used in December of a year will generate a new HMAC in January of the following year based on the new HMAC key.

In some businesses, this is not a relevant issue since the business process does not expect to query SAKA past the single transaction and will delete the ciphertext and HMACs of the plaintext at the end of each business cycle—a day, week, or month—after the transactions are “settled.”

However, if a business requires use of the same token for long durations—many years—and does not want the key rotation to impact applications and the token they store, they must use PSNs for their tokens.