We have had such problem a while ago and decided for AES128 (will update to AES256 at time) as our main encryption/decryption system for content packages. Signed by an RSA Key (yes I know RSA isnt that much safe) this completes our package format. In your case it depends on what do you try to do. Do you want to protect your Asset Data inside the packages or do you want to protect packages against modification?

Solutions

In the first case you need something fast that works on huge data when loading the package where in second case you would only need to encrypt your package header and keep anything else as readable as needed using SHA256 hash to protect package integrity. Any of these fitted well between protection and performance. Anything cross platform!

**As I got know currently Unreal 4 uses AES encryption too

The real problem

The most difficult thing is not to protect your content but to ship a key or something else that enables your game to decrypt the packages. Storing the key inside your App lets your customers find it in the source code or execution runtime what is the reason for such games to go on third party protection interfaces such as Steam or Denuvo that is on the way to get standard currently on AAA games.

The solution here is to think arround the edges. You could for example cipher your content with the original SHA256 hash of your games executable on each platform if you are able to determien that so you could protect your App against modification too (when anything changes in your games code the content will be useless) or you could write an algorithm that calculates a special key under special conditions you use so you wont have any clues in your game code and dont need to ship the key via network.

However, this is an interesting an difficult topic a whole industry works on and will go on work in the future. At end of day you need to decide what is it worth to

use a per-user seed -- encrypting the payload once per user. When a user starts up their game, have them connect to your server that tracks purchases by user ID (email address? phone number?) and serves the key to them.

I've actually thought about this some years ago, not because of pirating but because it makes a certain class of cheats which tampers with data files harder (or, as a simple public click-here-to-cheat solution, impossible?). But then you multiply the amount of data you need to distribute by the number of customers, so I said "Nobody on this planet is crazy enough to do that, and I shouldn't either".

Now that you proposed the same thing, do you know of anyone actually using per-user encrypted datafiles (successfully)?

I know the watermarking thingie is done extensively, especially in preview versions and such which are given out as "do not distribute". But that's a different story, and your audience is a lot smaller in that case too. Watermarking 3 journalists who are to review your game is very different from watermarking 3,000 paying customers and 300,000 people who download the trial but never buy the game.

We have had such problem a while ago and decided for AES128

What is your thread model? If your threat model is intercept-in-flight then that makes sense.
If you're trying to protect against actions taken by the user who has your program on their own machine, the strength of your crypto scheme or key management doesn't really matter.

then you multiply the amount of data you need to distribute by the number of customers

Every customer already downloads the full executable/installer, so I don't see how that changes? You need to be able to encode the data in real time on your download servers, which is a little bit of code to write, but that's not so bad. The main draw-back would likely be that you can't use a CDN when you get to scale.

Watermarking 3 journalists who are to review your game is very different from watermarking 3,000 paying customers

If your download servers can apply the watermark procedurally, then it doesn't matter how many different values you want to watermark with.