At first, I tended to agree with @fgrieu that this is not really a "cryptography" question.
If, it would belong more into the general information security corner, because – generally – the problem could be somewhat solved in software as well as in physical hardware. Yet, both software solutions as well as dedicated hardware solutions would still be subject to attackers using reverse engineering techniques which aim at gaining the ability to issue forced counter resets. Attacks like this will always be feasible; especially when the target is valuable from the perspective of an attacker.
Then again, this could very well be answered from a cryptographic point of view.
Is it possible for a cryptographic algorithm to limit the number of times a package/ciphertext can be decrypted?
No cryptographic (or non-cryptographic) algorithm is able to do that all by itself.
Let’s look at the facts:
- Unless there is a trusted party which controls the decryption counter, it is not possible to limit the number of times something is decrypted. (think: reverse engineering attacks.)
- Unless there is a trusted party which controls the data and data handling process, it is not possible to limit the data usage or even its destruction after a number of decryption counts. (think: attacks by repetition of the same decryption process using copies of data.)
So, yes this is possible if – and only if – we assume there is a trusted party. All we need to do is to add a trusted party to the mix (for example: you, or a trusted 3rd party) which controls the data – incl. decryption process, decryption counter, data storage, data handling, as well as the data destruction. The security of this solution would the rely on (a) the security of the cryptographic algorithm you use for encryption/decryption, and (b) the security of the trusted party who controls the data and its processing.In the end, it depends on the specific real world scenario (which you didn’t specify) how this could be implemented safest and most feasible.