[ACTION] Helper Functions — Sign Payload (RSA/HMAC) + Base64 Encode String

**Is there a specific app this action is for?**

Helper Functions (`pipedream_utils`, app_OD5h3W) — the no-auth utility app. Two related actions:

1. **[Text/Crypto] Sign Payload** (the one that unblocks us)
2. **[Text] Base64 Encode String** (small companion — the app has `base64-decode-string` but no encode)

**Please provide a link to the relevant API docs for the specific service / operation.**

Not a third-party API — this is Node's built-in `crypto`. Reference: [`crypto.sign()`](https://nodejs.org/api/crypto.html#cryptosignalgorithm-data-key-callback) / [`crypto.createHmac()`](https://nodejs.org/api/crypto.html#cryptocreatehmacalgorithm-key-options).

Concrete API this is needed for (public docs behind a free login, happy to share via the Slack channel): **NE DistriService API v1** — `POST https://orders.ne.nl/api/v1/auth` expects a `Signature` header containing `base64(RSA-SHA512(exact JSON request body, private key))`, and returns a bearer token with a max lifetime of 14 days. Equivalent in shell:

```bash
json='{"login":"user@example.com","nonce":"neople","lifetime":1209600}'
signature=$(printf '%s' "$json" | openssl dgst -sha512 -sign privkey.pem | base64 | tr -d '\n')
curl https://orders.ne.nl/api/v1/auth -H "Signature: $signature" -X POST --data "$json"
# → {"token":"eyJ...","expires":1789509904}
```

**Is lack of support preventing you from moving forward, or do you have a workaround?**

It is blocking, and the workaround does not scale. We run Pipedream components from Neople's own workflow builder, where our users compose registry actions — they cannot drop into a Node code step. So there is currently **no way to compute a signature anywhere in the chain**: `pipedream_utils` has no hash, HMAC, sign, or even base64-*encode* action, and the same is true of our own built-in actions.

**Are there specific actions or triggers you'd like to see for this app?**

**1. [Crypto] Sign Payload**

| Prop | Type | Notes |
|---|---|---|
| `payload` | string | The exact bytes to sign (usually a pre-rendered JSON body — sign it verbatim, no re-serialization) |
| `algorithm` | string, options | `sha256`, `sha384`, `sha512` |
| `mode` | string, options | `rsa` (default, `crypto.sign`), `hmac` (`crypto.createHmac`), ideally also `ecdsa` |
| `key` | string, **`secret: true`** | PEM private key (PKCS#8 and PKCS#1) for `rsa`/`ecdsa`, shared secret for `hmac` |
| `passphrase` | string, `secret: true`, optional | For encrypted private keys |
| `encoding` | string, options | `base64` (default), `base64url`, `hex` |

Exports: `{ signature }`.

Hard requirement on our side: the key prop must be `secret: true` so it never appears in step exports, `configured_props`, or run logs — same treatment as any credential.

**2. [Text] Base64 Encode String**

Mirror of the existing `base64-decode-string`: input `data` (string), optional `inputEncoding` (`utf8` | `binary`), exports `{ encoded }`. Useful on its own, and the pair makes `sign` composable for APIs that want a differently-wrapped signature.

*(For Neople)*

Locate the pipedream_utils app and its existing base64-decode-string action, then read the Node crypto.sign() and crypto.createHmac() documentation linked in the issue. Confirm the two requested actions accept the specified inputs, keep key and passphrase props secret, and produce the requested signature or encoded output; validate the RSA example and Base64 behavior with the project’s tests.

Written by the indexing model from the issue text.