Store a checksum of the encrypted file, best together with the file, maybe appended to the end.

If you meant something different, you may want to try to explain it...

update

btw: Trying to decrypt it should be enough, I'm not aware of any common encryption which can be reversed if corrupted.

but storing a checksum of the encrypted file will be useless wouldnt it? because i am not sure if even the first file will be corrupted. i wouldnt want to generate a hash for a corrupted file to check with. i need to check the first original file for corruption. and like i say, the file cannot be decrypted because the keys to decrypt it are unknown afaik :l

the next idea i had would be checking it for randomness. an excrypted files should be very low or null on repeating byte characters, shouldnt it? but how do you check a file for byte character randomness, or randomess at all? <.<

The idea is to generate the checksum right after encryption has occurred. Then whenever the integrity of the file needs to be checked, the checksum of the encrypted file can be recomputed and compared to the baseline value. This will detect corruption to a high level a confidence, if a suitable checksum function is used. It appears in your case that this was not done, so there is no baseline with which to compare. Detecting if the encrypted files have been corrupted from their original state is now impossible.

Computing the checksum of the files in their current state will enable you to detect any further corruption. If the concern is deteriorating media, this might be useful.

I understand that certain encryption methods leave telltales in their encrypted files, some of which could be detected via a statistical analysis. This would allow you to tell if a certain file still looks "pretty much like most files encrypted using this method." If that would actually provide any level of reassurance to you, go for it.