# Ignoring the TAG of the AEAD-SIV encryption

I am working with personal data that contain Identifying attributes such as a player ID and i need to prepare the data for analysis purposes, therefore i need to pseudoanonymize the data beforehand. However, the data should be pseudo-anonymized in a deterministic way in order to always have the same pseudo-anonym for the same player ID.

While searching through different sources, i ended up working with the encryption AEAD-SIV method mode implemented https://pycryptodome.readthedocs.io/en/latest/src/cipher/modern.html?highlight=siv#siv-mode where i specify a fixed nonce.

AEAD by definition creates a ciphertxt and a tag for each plaintext message and no one can decrypt the ciphertext except when providing the tag. Therefore, from my side because i dont need to decrypt the ciphertext after encryption , i am only storing the ciphertext and completely ignoring the tag upon creation.

Therefore my questions:

1- Does it decrease the level of security of the encryption if we do not store the tag?

2- Also, In some cases am specifying a fixed padding in order to not have ciphertexts with different lengh. Does this process affect the level of security of the encryption?

3- Is AEAD-SIV still considered a standard for deterministic encryption? (I read about AEAD-GSM-SIV but there doesnt seem to be any available implementation yet).

• What is the size of ID? You can use AES with a fixed key in that way it is a random permution. Mar 4 at 13:17
• The ID should be usually less than 20 characters . I am basically using AES with 256 bit key however in SIV mode Mar 4 at 14:15
• Character is hex or something? can you pack them 16-byte? Is there a problem if you encrypt in two blocks? In this case, some information can be leaked. Mar 4 at 14:18

Short answer: AEAD is completely the wrong tool for the job. You need a MAC, or perhaps a hash.

Here are two important facts about cryptography:

• Details matter. You can't just take a good, secure construction and modify it and expect it to remain secure.
• Cryptography is not limited to encryption.

from my side because i dont need to decrypt the ciphertext after encryption

If you don't decrypt, why would you encrypt? The whole point of encryption is that it can be decrypted if you have the key.

If you want to transform private identifiers into pseudonymous identifiers, a basic tool is a hash function. (More precisely, a cryptographic hash function: hash functions are also used outside cryptography. In a cryptographic context, "hash" means a cryptographic one.) Hash functions have the property that given y = H(x) but not x itself, the only way to recover $$x$$ is to guess it. This is probably not good enough in your case because anyone could just get a list of player IDs, or guess them, and calculate their hashes.

You can throw a secret key into the mix. With a MAC function M and a secret key k, given y = M(k, x) but not x or k, it's impossible to find x (or even to determine whether there is a valid x at all). Furthermore, given x and y but not k, it's still impossible to determine (or even make a good guess) whether y corresponds to this x. So you can use a MAC with a secret key, and only people with the secret key can associate player IDs with pseudonymous IDs in either direction.

Given the key k and a pseudonymous ID y, it's at the very least possible to guess x and verify whether M(k, x) = y. If you can't figure out x by guessing, it may still be possible to use the knowledge of k and y to get candidate x. Whether this is possible depends on the nature of the MAC. A popular class of MAC functions, HMAC, has the property that even with the key, it's impossible to find x other than by guessing, similar to the property of hash functions. (And for the same underlying reasons: HMAC leverages a hash function to build a MAC function.) HMAC is a good choice of MAC regardless of whether you care about this property.

Given your problem statement, I think HMAC matches your requirements. However, I am unsure whether your technical requirements match your expectations on privacy. I would recommend that you consult with an expert on privacy.

AEAD by definition creates a ciphertxt and a tag

Not necessarily. In general, AEAD encryption creates a ciphertext and decryption takes this ciphertext as input, plus the key, nonce and additional data, and either returns the plaintext or a decryption failure report. It is true for many AEAD mechanisms, including SIV, that the ciphertext can be broken up into a tag which is necessary to determine whether the ciphertext is authentic and a ciphertext-without-tag which is sufficient to recover the plaintext if the ciphertext is authentic. But this decomposition is not an intrinsic requirement of AEAD and is not a useful way to process AEAD functionally.

no one can decrypt the ciphertext except when providing the tag

This is wrong (for AEAD modes that do have a distinctive tag, which includes SIV and most others). Without the tag, it's still possible to decrypt the ciphertext, in the sense that it's possible to find the original plaintext. It's just not possible to determine whether the plaintext is authentic.

Does it decrease the level of security of the encryption if we do not store the tag?

Not as such. If you don't store a part of the ciphertext, it can reduce the security of authentication (you lose part of your ability to verify that the data is genuine), but not the security of encryption (erasing some information doesn't reduce the confidentiality of data).

However, not verifying the tag can reduce the security of the encryption – see next paragraph.

Also, In some cases am specifying a fixed padding in order to not have ciphertexts with different lengh. Does this process affect the level of security of the encryption?

Maybe: padding can allow padding oracle attacks. The gist of a padding oracle attack is that an attacker makes up some fake ciphertexts and asks you to decrypt them. You decrypt, and verify the padding. If the response reveals something about the validity of the padding, this can allow the attacker to decrypt arbitrary ciphertexts, or perhaps only ciphertexts in a certain format. This happens if there's some way to present part of the plaintext as padding, which there usually is since the point of padding is to be in the place where some plaintext would be if it was longer. The details depend on the nature of the padding and the encryption.

AEAD is invulnerable to padding oracle attacks because the attacker can't make up valid ciphertexts. (Also, most common AEAD modes don't have padding – but even if they did, the authentication would protect them.) That, of course, goes for AEAD used as such. If you take an AEAD construction and throw some parts out, all bets are off.

Is AEAD-SIV still considered a standard for deterministic encryption?

Yes, if you needed deterministic authenticated encryption, then SIV would be a good choice.

• Thanks for the detailed answer. I ended up using the HMAC-sha3-256 hashing algorithm with a 128 bit randomly generated key. Therefore i have two questions : 1- Is sha3-256 considered a standard when it comes to hashing algorithms or should I always use sha2-256 ? . 2- Should the key length be different ? Mar 11 at 7:23
• @user3160046 Either SHA3 or SHA2 is fine. With SHA3, KMAC is slightly faster than HMAC, as secure and more standard, but HMAC is ok too. 128 bits is needlessly small for a HMAC key; usually the HMAC key is as long as the hash (and key length doesn't affect performance at all). Mar 11 at 17:12