Some of the code is shared between implementations (IByteConverter<T> for example). This should be segregated from the Json Serializer-specific packages.

Adding a basic level of configuration support from the shared kernel would be ideal, as well.

Decorating a class/struct will always encrypt that object, whether it's decorated when used as a Field/Property or not.

Everything that's serialized is encrypted by default. To not encrypt a given field/property, it must be explicitly defined.

JsonCryption
JsonCryption.Newtonsoft
JsonCryption.System.Text.Json

I don't want to support a serializer that doesn't serialize/deserialize private fields/properties... at least not yet. Let's investigate if Jil can handle that (because it wasn't clear in the documentation or after a cursory glance at the tests).

If it's possible, then I should create a version for Jil. Otherwise, let's skip it for now and stick to Utf8Json for the higher-performing serializer.

Go easy on the GC by using streams in place of temporary objects internally.

For example:

class Parent
{
    // this works correctly already
    [Encrypt]
    public int MyInt { get; set; }

    // this needs confirmed that the entire class should be encrypted
    [Encrypt]
    public FullChild { get; set; }

    // this needs confirmed that the nested fields marked for encryption are properly encrypted
    public PartialChild { get; set; }
}

class FullChild
{
    ...
}

class PartialChild
{
    // this should be nested and encrypted above
    [Encrypt]
    public int MyEncryptedInt { get; set; }

    // this should be nested, but should NOT be encrypted above
    public string MyUnencryptedString { get; set; }
}

I know this issue already exists... I wanted a quick practice at linking issues.

1. On every commit to master, a ci package is created and published, with the version suffix including the date/time of the build

2. On every commit to master with a beta tag, a beta package is created and published, also with the version suffix including the date/time of the build

3. On every commit to master with a release tag, a package is created with the included version, and published if the version doesn't already exist

DotNet Core 3.1 already has a full-featured and relatively easy-to-use data protection package for encryption, key management, algorithm management, etc.

This should depend on that for all protection logic.

Expected

This should work:

var builder = new StringBuilder();
using (var textWriter = new StringWriter(builder))
serializer.Serialize(textWriter, instance);

var json = builder.ToString();

using var textReader = new StringReader(json);
using var reader = new JsonTextReader(textReader);
var decrypted = serializer.Deserialize<HashSetParent>(reader);

class Foo
{
    [JsonProperty]
    [Encrypt]
    public readonly HashSet<CustomObject> _items = new HashSet<CustomObject>();
}

class CustomObject
{
    ...
}

Actual

Throws a NullReferenceException in GenericValueProvider.SetValue at the test line:

var decrypted = serializer.Deserialize<HashSetParent>(reader);

The Singleton feels like an anti-pattern. This should be fixed.

As an alternative option to opting in to encryption by attribute decoration, not a complete replacement

The different packages are completely independent from each other. Their versions shouldn’t change unless they actually change. Each should be independently versioned from the others.

https://github.com/neuecc/Utf8Json