This is easy to do with a trusted third party. Yes, I know, you probably want a solution that does not need it, but carry me. we get to this, or at least close to it.
In any case, if you have a suitable trusted third-party organization, it’s easy: after encrypting your file with AES, you simply send your AES key to a third party, ask them to encrypt it with your key , send the result back to you and publish your key at a specific time in future. At this point (but not earlier), anyone with an AES encrypted key can now decrypt it and use it to decrypt the file.
Of course, a third party may require many key encryption keys, each of which will be published at a different time. Instead of storing them all on disk or something else, an easier way is to generate each key encryption key from a secret master key and an assigned release time, for example. applying the appropriate key generation function to them. Thus, a separate and (apparently) independent key can be generated for any desired release date or time.
In some cases, this solution can be practical. For example, a “trusted third party” may be an unauthorized access protected hardware security module with a built-in real-time clock and a secure external interface that allows keys to be encrypted for any release date, but should only be decrypted for past dates.
However, if the trusted third party is a remote entity providing a global service, sending each AES key for them to encrypt can be impractical, not to mention a potential security risk. In this case , public key cryptography can provide a solution: instead of using symmetric encryption to encrypt file encryption keys (for which they need to know the file encryption key or unlock the key encryption key), a trusted third-party organization can instead generate a pair of public / private keys for each release date and publicly publish the open half of the key pair, but refuse to disclose the private half before the specified release date. Anyone holding a public key can encrypt their own keys, but no one can decrypt them until the corresponding private key is revealed.
(Another private solution would be to use a secret exchange to split the AES key into shares and send only one share to a third party used for encryption. Like the public key solution described above, this will avoid disclosing the AES key to a third party, but unlike public key solutions will still require two-way communication between the cipher and a trusted third party.)
The obvious problem with both of the above solutions is that you (and everyone else) need to trust a third party generating the keys: if the third party is dishonest or compromised by an attacker, they can easily divulge private keys ahead of time.
There is, however, a clever method published in 2006 by Michael Rabin and Christopher Thorpe (and mentioned in this answer to crypto.SE by one of the authors) that at least partially addresses the issue. The trick is to distribute key generation to a network of several more or less reliable third parties in such a way that even if a limited number of parties are dishonest or compromised, none of them can learn secret keys until a sufficient majority of parties agree that it is really time set them free.
The Rabin and Thorpe protocol also protects against many other possible attacks by compromised parties, such as attempts to prevent the secret keys from being revealed at the appointed time or to cause the generated private or public keys to not match. I do not claim to fully understand their protocol, but, given that it is based on a combination of existing cryptographic methods of existing and well-studied studies, I see no reason why it should not comply with the declared security specifications.
Of course, the main difficulty here is that in order for these security specifications to actually be anything useful, you need a distributed network of key generators large enough so that no attacker can plausibly compromise a sufficient majority of them. Creating and maintaining such a network is not a trivial exercise.