Add Support for calling libsodium crypto_aead_aes256gcm_encrypt_detached and crypto_aead_aes256gcm_decrypt_detached

[JpGallegos]

Description

I would like to request the addition of support for calling the crypto_aead_aes256gcm_encrypt_detached and crypto_aead_aes256gcm_decrypt_detached functions from the libsodium library.

Proposed API

The proposed API could look similar to existing AEAD functions in the Nsec library, but with additional parameters for handling the detached tag. For example:

public void EncryptDetached(
    Key key,
    ReadOnlySpan<byte> nonce,
    ReadOnlySpan<byte> associatedData,
    ReadOnlySpan<byte> plaintext,
    Span<byte> ciphertext,
    Span<byte> tag);

public bool DecryptDetached(
    Key key,
    ReadOnlySpan<byte> nonce,
    ReadOnlySpan<byte> associatedData,
    ReadOnlySpan<byte> ciphertext,
    ReadOnlySpan<byte> tag,
    Span<byte> plaintext);

[samuel-lucas6]

May I ask what use case is this for? Are you forced to prepend the tag?

[JpGallegos]

We're working with code that handles the ciphertext and tag separately to encrypt/decrypt real time communication packets. Processing the output of the combined AES-256-GCM methods to work with the codebase adds undesired latency.

[samuel-lucas6]

We're working with code that handles the ciphertext and tag separately to encrypt/decrypt real time communication packets. Processing the output of the combined AES-256-GCM methods to work with the codebase adds undesired latency.

Thanks for your reply. In what way? You can't decrypt without verifying the tag. The combined API shouldn't be a problem.

[JpGallegos]

Can't go into much detail, but, basically, the packets are encrypted and decrypted a few times in different places. Some of those places have libraries that work with the ciphertext and tags in different buffers (detached mode); we could take the combined output and separate them into different buffers, but that adds overhead which can be completely eliminated by just using the detached methods.

[samuel-lucas6]

Can't go into much detail, but, basically, the packets are encrypted and decrypted a few times in different places. Some of those places have libraries that work with the ciphertext and tags in different buffers (detached mode); we could take the combined output and separate them into different buffers, but that adds overhead which can be completely eliminated by just using the detached methods.

Ah ok. I'm guessing you can't use spans or this is interacting with something in another programming language.

The trouble is the detached API is basically duplicate functionality. If I was designing a library and worried about this problem, I would just expose a detached API, which is what the .NET AES-GCM does. However, the tag is typically appended, so the combined API generally seems preferable and less confusing to the user.

Your PR also only covers AES-GCM, which would make the API inconsistent with the other AEAD schemes. However, I recommend waiting for ektrah to reply before adding anything else. I expect he's busy with work.

[ektrah]

Apologies for the delayed response.

There are two relevant interfaces for AES-GCM encryption:

• AES-GCM encryption as defined in NIST SP 800-38D produces two outputs: the ciphertext and the authentication tag (Section 7.1 of NIST SP 800-38D).

• The AEAD interface as defined by RFC 5116, on the other hand, does not have the concept of detached tags. AEAD encryption is expected to produce a single output: the ciphertext, which may be longer than the plaintext (Section 2.1 of RFC 5116).

For AES-GCM to implement the AEAD interface, the two outputs are combined through concatenation (Section 5.1 of RFC 5116). However, other algorithms implementing the AEAD interface may do this differently.

NSec is intended to provide the AEAD interface, rather than the AES-GCM interface. While NSec could potentially offer both interfaces, I think this would make it more confusing to use. Considering that .NET already provides the AES-GCM interface through the AesGcm class, I'm leaning towards keeping the NSec API simple.