DDD - Behavior with optional state: Service / Value Object?

Question

Following DDD practices, I am running into a problem while implementing a small AES encryptor/decryptor (wrapping .NET's AesCryptoServiceProvider).

public class Aes256CbcCryptor : ISymmetricCryptor
{
    private SymmetricAlgorithm AesProvider { get; set; }

    // Poor man's DI - beside the point
    public Aes256Cbc()
    {
        this.AesProvider = new AesCryptoServiceProvider()
        {
            BlockSize = 128,
            KeySize = 256,
            Mode = CipherMode.CBC,
            Padding = PaddingMode.PKCS7,
            Key = // OH DEAR IT TAKES STATE
        };
    }
    public Aes256Cbc(SymmetricAlgorithm aesProvider)
    {
        this.AesProvider = aesProvider;
    }

    public byte[] Encrypt(byte[] keyBytes, byte[] plaintextBytes)
    {} // TODO
    public byte[] Decrypt(byte[] keyBytes, byte[] ciphertextBytes)
    {} // TODO
}

As you can see, .NET's AesCryptoServiceProvider is stateful - it takes a key as a property. But as I've come to understand, services are not supposed to be stateful.

1. Is the key being a property (rather than, say, a method parameter) the main thing going wrong here?
2. How would you implement the class in a DDD way?
3. In some situations, having a provider initialized with a given key seems useful and efficient (if that key is to be used a lot). Is there a justification for stateful services, or an alternative?

I imagine we could just instantiate a new Provider on every method call, but it seems very wasteful. We could implement caching to reduce the waste, but the whole thing then starts feeling overengineered.

Another alternative I have come up with is to create an Aes256CbcCryptorFactory instead. The factory's CreateCryptor(byte[] key) returns a Value Object Aes256CbcCryptor that is actually stateful. A consuming service could now at least keep this object around in the scope of one of its methods, if it needs to make multiple cryptor calls.

On the other hand, such a consuming service could still not store the Value Object in one of its properties, as doing so would make that service stateful.

4. Seeing as there are some benefits, is this a thing that is done? The type of behavior seems very servicey for a Value Object, but at least we can have some temporary state.

Answer 1

I would go with something like this:

public class Aes256CbcCryptor : ISymmetricCryptor
{
    private SymmetricAlgorithm AesProvider { get; }

    public Aes256CbcCryptor(Byte[] key)
    {
        // AesCryptoServiceProvider is not a 'volatile' dependency
        // therefore we don't need to inject it.
        this.AesProvider = 
            new AesCryptoServiceProvider()
            {
                ...
                Key = key// This is the real dependency, IMHO
            };
    }
}

Then the composition root, using 'poor man's DI' would like this:

public static sub Main()
{
    var key = SomeConfigSomewhere.GetSetting["key"];

    var cryptor = new Aes256CbcCryptor(key);

    var cipherText = cryptor.Encrypt("P@55w0rd");
}

Using a container would make resolution more neat but would essentially be the same:

public static sub Main()
{
    arbitraryContainer
        .Register
        .ServiceFor<ISymmetricCryptor>()
        .Using<Aes256CbcCryptor>()
        .DependingOn(SomeConfigSomewhere.GetSetting["key"]);

    var cryptor = arbitraryContainer.Resolve<ISymmetricCryptor>();

    var cipherText = cryptor.Encrypt("P@55w0rd");
}