Cool thanks. Now I'm wondering: how would one use it to encrypt all the cached values?
Can you please share a DI configuration that would work to do so?
I think overriding the cache.default_marshaller service would work.
When we have something that works, we might wonder about whether this is good enough or if we need better configurability.

@nicolas-grekas I added in the description an example of how to use the SodiumMarshaller by decorating the default cache.default_marshaller

And here is the test I did

// add an item to cache
public function __invoke(CacheItemPoolInterface $cache)
{
    $item = $cache->getItem('framework')->set('symfony');
    $cache->save($item);
}

The value of our item is encrypted in the filesystem cache.

And when we retrieve the item

// add an item to cache
public function __invoke(CacheItemPoolInterface $cache)
{
    $item = $cache->getItem('framework');
    dump($item->isHit()); // true
    dump($item->get());   // "symfony"
}

Great thanks,

- '%env(file:resolve:SODIUM_DECRYPTION_FILE)%'

next step would be documenting how we generate this content
OR: do we want any integration with the secret vault? there is already a SYMFONY_DECRYPTION_SECRET that is used by default there, can/should we leverage it?

I think we could use the keys generated by SodiumVault, but there is a problem, what will happen if the user generates new wkeys and overrides the existing ones ?

I don't know if this exists already or not, but what about offering to the user (or just internally) the possibility to generate multiple encrypt/decrypt keys, by having this we can generate and use a specific key for the cache (we can also go far and use a different key for each cache pool).

what will happen if the user generates new wkeys and overrides the existing ones ?

Very good point. This means we should handle one (or more) fallback keys that could be used to decrypt values when the main one doesn't work. That would allow rotating keys gracefully.

So we can have something like that?

- __construct(string $decryptionKey, MarshallerInterface $marshaller = null)
+ __construct(string $decryptionKey, MarshallerInterface $marshaller = null, array $fallbackDecryptionKeys = [])

I'm wondering now where we will store fallback keys and how the user can manage them

What about __construct(array $decryptionKeys, MarshallerInterface $marshaller = null)?

I'm wondering now where we will store fallback keys and how the user can manage them

We'd need to experiment ideas.

What about __construct(array $decryptionKeys, MarshallerInterface $marshaller = null)?

Yes, better than what I suggested.

We'd need to experiment ideas.

What do you think about a new command that we can use to generate not only one secret key (as we have now with secrets:generate-keys) but as much as we need ?
Instead of generating one secret key per env, we can give a name or a prefix to each one

For example: bin/console keys:generate cache will generate a secret key that we can use only for the cache SodiumMarshaller

Thank you @atailouloute.