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.
