feat: "Spanify" DataProtector

[DeagleGross]

Please, review with caution! This is cryptography and failures here can be pretty dramatic...

This PR introduces 2 new interfaces which allow usage of DataProtection via Span<byte>: ISpanDataProtector and IAuthenticatedEncryptor.

Details

Current PR proposes extra interfaces ISpanDataProtector and ISpanAuthenticatedEncryptor (Inspiration taken from ISpanFormattable : IFormattable). The APIs are:

namespace Microsoft.AspNetCore.DataProtection;

+ public interface ISpanDataProtector : IDataProtector
+ {
+     int GetProtectedSize(int plainTextLength);
+     bool TryProtect(ReadOnlySpan<byte> plainText, Span<byte> destination, out int bytesWritten);

+     int GetUnprotectedSize(int cipherTextLength);
+     bool TryUnprotect(ReadOnlySpan<byte> cipherText, Span<byte> destination, out int bytesWritten);
+ }

and

namespace Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption;

+public interface ISpanAuthenticatedEncryptor : IAuthenticatedEncryptor
+ {
+     int GetEncryptedSize(int plainTextLength);
+     bool TryEncrypt(ReadOnlySpan<byte> plaintext, ReadOnlySpan<byte> additionalAuthenticatedData, Span<byte> destination, out int bytesWritten);

+     int GetDecryptedSize(int cipherTextLength);
+     bool TryDecrypt(ReadOnlySpan<byte> cipherText, ReadOnlySpan<byte> additionalAuthenticatedData, Span<byte> destination, out int bytesWritten);
+ }

From the implementation standpoint, these APIs are basically doing what existing Protect() / Unprotect() and Encrypt() / Decrypt() do, but without allocating a result array and instead filling in the Span<byte> destination.

For IAuthenticatedEncryptors I tried to reuse the TryEncrypt/TryDecrypt from Encrypt/Decrypt where possible to reduce code duplication.

Registrations

IDataProtector also should implement IDataProtectionProvider which provides the protector instance:

public interface IDataProtectionProvider
{
  IDataProtector CreateProtector(string purpose);
}

And in default DI (AddDataProtection) IDataProtector is created in such a manner:
https://github.com/dotnet/aspnetcore/blob/b52c80fef2b8bf5239c7643d9c79d1029bb6c988/src/DataProtection/DataProtection/src/DataProtectionServiceCollectionExtensions.cs#L89C13-L95C14

I dont want to introduce more APIs and interfaces for providing ISpanDataProtector and instead when providing I am doing a lookup to determine whether it is possible to return ISpanDataProtector or IDataProtector. Users will then be able to differentiate based on their needs and registrations.

Usage

Having IDataProtector:

void Do(IDataProtector protector, ReadOnlySpan<byte> plaintext)
{
    if (protector is ISpanDataProtector spanDataProtector)
    {
        // Use the Span API
        
        var destination = new byte[spanDataProtector.GetProtectedSize(plaintext.Length)];
        if (spanDataProtector.TryProtect(plaintext, destination, out var bytesWritten))
        {
            Console.WriteLine($"Protected {bytesWritten} bytes using Span API.");
        }
    }
    else
    {
        var ciphertext = protector.Protect(plaintext.ToArray());
        Console.WriteLine($"Protected {ciphertext.Length} bytes using regular API.");
    }
}

and the same goes for IAuthenticatedEncryptor, but I doubt majority of users implement their own IAuthenticatedEncryptor.

Testing

In order to verify correctness of the changes I've created RoundtripEncryptionHelpers.AssertTryEncryptTryDecryptParity where I try to call Encrypt/Decrypt in different order for IDataProtector and IAuthenticatedEncryptor to ensure any order of operations give a correct roundtrip result.

I will also change any other place in aspnetcore to use this API to make sure new APIs behave correctly and in the same way as existing APIs

Fixes #44758

[Copilot]

Pull Request Overview

This PR adds new non-allocating "Span-based" APIs to the DataProtection interfaces, specifically implementing the Protect/Encrypt functionality without requiring heap allocations. The new APIs allow callers to get the size of protected data upfront and then encrypt directly into a provided buffer.

Key changes:

• Added GetProtectedSize() and TryProtect() methods to IDataProtector interface
• Added GetEncryptedSize() and TryEncrypt() methods to IAuthenticatedEncryptor interface
• Implemented these methods across all encryptor types (AES-GCM, CBC, CNG variants, Managed implementations)

Reviewed Changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/DataProtection/Abstractions/src/IDataProtector.cs	Added new span-based APIs to the main data protector interface
src/DataProtection/DataProtection/src/AuthenticatedEncryption/IAuthenticatedEncryptor.cs	Added new span-based APIs to the authenticated encryptor interface
src/DataProtection/DataProtection/src/KeyManagement/KeyRingBasedDataProtector.cs	Core implementation of new APIs with proper header management
src/DataProtection/DataProtection/src/Managed/ManagedAuthenticatedEncryptor.cs	Implementation for managed (non-CNG) encryption algorithms
src/DataProtection/DataProtection/src/Managed/AesGcmAuthenticatedEncryptor.cs	Implementation for AES-GCM encryption
src/DataProtection/DataProtection/src/Cng/CbcAuthenticatedEncryptor.cs	Implementation for CNG-based CBC encryption
src/DataProtection/DataProtection/src/Cng/CngGcmAuthenticatedEncryptor.cs	Implementation for CNG-based GCM encryption
src/DataProtection/Extensions/src/TimeLimitedDataProtector.cs	Updated time-limited protector to support new APIs
Multiple test files	Comprehensive test coverage for the new functionality

[halter73]

I think we should update our existing code that calls into IDataProtecter to use the new methods to get good test coverage of the new methods.

[martincostello]

Was just looking at some profiles for one of my apps and spotted that DataProtection was on the hot path for rendering a page:

I think that ultimately comes down to here:

aspnetcore/src/Antiforgery/src/Internal/DefaultAntiforgeryTokenSerializer.cs

Line 156 in 1202a8f

var bytes = _cryptoSystem.Protect(stream.ToArray());

Might be an interesting code path to try out the new APIs added here once merged.

[DeagleGross]

@martincostello that was the initial idea - to improve Antiforgery and other places where DataProtection is used under the hood - for example Blazor.

I have some starters for Antiforgery perf improvements, but this one was the biggest blocker to make an alloc-free flow and I hope this and follow-up changes will help there

[DeagleGross]

Pushed the dotnetbenchmark project showing the updated numbers. Results on my machine: