Alternative flexible AEAD API better suited for dynamic scenarios

[tomekmarchi]

I will focus on xChacha as the context. The current API returns a compiled object with encrypt/decrypt where it would require re-generating in dynamic scenarios. This leaves the API less flexible than say the xChaCha API we find in sodium-native/libsodium which allows greater flexibility for such cases where these initial arguments change.

The main thing to point out is related to additional data arg here's a simple context:
Your additional data is unique per packet
This would require modifying the existing Additional Data buffer (even though you already have a specific buffer for additional data anyway - could also possibly have multiple ADD Buffers at a given time) that was already used initially to generate the encrypt/decrypt functions or to regenerate the cipher object entirely.

Preferably all initial args key, nonce, ADD would be moved to encrypt/decrypt functions. I can see the benefits of pre-computing functions/methods. However, it would be nice to expose a more flexible alternative API that is more viable for specific dynamic scenarios.

[paulmillr]

Just make a 1 line helper function if you like your idea of API.

xchacha = (key, nonce, aad, data) => xc(key, nonce, aad).encrypt(data)

There is no "non-flexibility". You can make any custom function.

[tomekmarchi]

Yes, I understand that and is what I'd like to avoid specifically being forced into constant cipher object regeneration.

Take specifically xchacha20poly1305
For sake of sanity imagine this.

export const _poly1305_aead =
  (xorStream: XorStream) =>
// No cache of variables can store cipher object and access methods immediately no regen/buffer mods
// Can still do precompute steps for key/nonce which is viable would only require buffer mods then to still use the initial cipher object
  (): CipherWithOutput => {
    const tagLength = 16;
    return {
      encrypt(key: Uint8Array, nonce: Uint8Array, AAD?: Uint8Array, plaintext: Uint8Array, output?: Uint8Array) {
        
      },
      decrypt(key: Uint8Array, nonce: Uint8Array, AAD?: Uint8Array, ciphertext: Uint8Array, output?: Uint8Array) {

      },
    };
  };

The API would be similar to (sodium-native) but could have a level of pre-compute like current setup
crypto_aead_xchacha20poly1305_ietf_encrypt(originalMessage, add, nonce, key);

Imagine a network server/client

xchacha20poly1305 would then function more like the below options

// without key or nonce precompute step
xchacha20poly1305.encrypt(key, none, message, add);

// static key with precompute function (pretend automatic nonce management auto randomizes existing buffer)
xchacha20poly1305.encrypt(message, add);

For decrypt its a different story for the nonce
Each packet will have a unique nonce and add lets just imagine the key is the same

// With auto nonce extraction and same key
xchacha20poly1305.decrypt(message, add);

// without auto extract of nonce
xchacha20poly1305.decrypt(message, nonce, add);

//without any precompute but doesn't require generating new functions/objects at all
xchacha20poly1305.decrypt(key, message, nonce, add);

I can modify the current codebase to show you a demo of these different options some of which would be more performant by allowing someone to avoid constantly regenerating cipher objects and or at best cloning buffer data etc when dealing with new vars. I can also show examples where these varying options would be more flexible and at least in my case more performant.

I'm happy to submit a pull request with these alternative options. What I can say is the current API locks me into constant cipher object regeneration (due to not dealing with the same initial vars used to generate the cipher object) these alternative API options would offer greater flexibility (certainly for server/client cases) while avoiding redundant operations such as constant cipher objects.

[paulmillr]

I am not sure what you are talking about. "Re-generating cipher object" takes 0.000006 seconds. You can do it 200000 times per second. It does not matter.

import * as c from '@noble/ciphers/chacha';
const k = new Uint8Array(32).fill(2);
const n = new Uint8Array(12).fill(3);
const n24 = new Uint8Array(24).fill(4);
// warm-up
c.chacha20poly1305(k, n);

console.time();
c.chacha20poly1305(k, n);
console.timeEnd();

console.time();
c.xchacha20poly1305(k, n24);
console.timeEnd();

[tomekmarchi]

You are getting closer to what I'm speaking about but I will try to better convey a context/define things because that is what is missing above. Running individually or a small amount isn't the concern just to be clear.

"cipher object" = what I'm calling the object returned from xchacha20poly1305(key, nonce, add)

I will try to convey a realistic scenario imagine many clients (many different keys) sending many packets.

Now imagine nonce, add changes per packet constantly with keys changing twice per client

The nonce changes with each encrypt/decrypt and isn't know for decrypt prior to receiving the packet, and add is different per packet thus making it as an initial arg none-viable for this context and leads to redundant operations which en masse is where problems become apparent. More to be said but gets general context across.

In a dynamic context (realistic scenario) such as network/protocol (server/clients) related just having it as bare encrypt/decrypt functions would be faster & less taxing than the current API which in my case I'm forced to be generating objects like it's its day job which I assure you should indeed not be its day job.

Imagine over and over en masse
xchacha20poly1305(key, nonce, add).encrypt(msg);

Thus a bare function which does't require the generation of the "cipher object" is more flexible for cases where things are constantly changing. (Cipher object is already generated without the initial vars) similar to libsodium API.

xchacha20poly1305.encrypt(key, nonce, add, msg);
Notice no pre-compute step resulting in the generated & returned "cipher object". It already exists on the xchacha20poly1305 object and doesn't return an object only the encrypted text of course with the concatenated nonce.

I fully understand the reason for the pre-compute and the performance that comes from it for scenarios that benefit from such a context but for dynamic scenarios with many clients with ever changing variables it actually creates needless memory allocations and redundant operations.

Again I want to stress it's not that the current API is bad rather its perfect for the scenarios which are most applicable to it. I want to make it clear I'm merely advocating for an alternative additional API for the contexts which would benefit from not having to do xchacha20poly1305(key, nonce, add).encrypt(msg) constantly such as mine/above scenario.

[paulmillr]

I am still not sure why we're having this conversation. Did you provide performance dumps with traces for every internal method describing what's slow and what's not? It seems like you don't know what you're talking about and operate on "it would be good to have" basis instead of precise performance metrics.

would be faster & less taxing

bare encrypt/decrypt functions would be faster & less taxing than the current API

Current API is fast, you can create cipher object 200000 times per second.

needless memory allocations

There are no needless memory allocations. You can reuse existing buffers for inputs, outputs, keys, nonces, and everything else. The API ensures it's possible.

precompute

There is no precomputation. The function simply returns another object / function. The overhead is just one function call. Which basically means there is no overhead.