Overview
The encrypt node provides AES encryption and decryption for
protecting sensitive data in your flows. It supports AES-GCM (authenticated encryption with
integrity verification) and AES-CBC (classic block cipher mode). Use it to secure sensor data
before transmitting over MQTT, protect configuration values in storage, or decrypt payloads
received from secure sources.
Properties
| Property | Type | Default | Description |
|---|---|---|---|
| operation | string | "encrypt" | Operation: "encrypt" or "decrypt" |
| algorithm | string | "AES-GCM" | Encryption algorithm: "AES-GCM" or "AES-CBC" |
| key | string | "" | Encryption key (256-bit recommended) |
| encoding | string | "hex" | Output encoding: "hex" or "base64" |
| property | string | "payload" | Message property to encrypt or decrypt |
Algorithm Comparison
AES-GCM (Recommended)
Authenticated encryption. Provides both confidentiality and integrity. Automatically detects if data has been tampered with during decryption.
- Generates authentication tag automatically
- Tampered data is rejected on decryption
- Random IV generated per encryption
- Industry standard for modern applications
AES-CBC (Legacy)
Classic block cipher mode. Provides confidentiality only. No built-in integrity check. Use when interoperating with older systems.
- No authentication tag
- Requires separate HMAC for integrity
- PKCS7 padding applied automatically
- Compatible with legacy systems
Example: Encrypt Sensor Data Before MQTT Publish
Encrypt sensor readings before publishing to an MQTT broker for secure data transport.
// Encrypt node configuration
{
"operation": "encrypt",
"algorithm": "AES-GCM",
"key": "${ENCRYPTION_KEY}",
"encoding": "base64",
"property": "payload"
}
// Flow: [Sensor] -> [JSON Stringify] -> [Encrypt] -> [MQTT Out]
//
// Before encryption:
// msg.payload = '{"deviceId":"sensor-01","temp":22.5,"humidity":65}'
// msg.topic = "sensors/encrypted/sensor-01"
//
// After encryption (AES-GCM):
// msg.payload = {
// "iv": "a1b2c3d4e5f6a7b8c9d0e1f2",
// "data": "kJ7xM2pQrN8vF5hL3wYzA9bC6dE...",
// "tag": "x9y8z7w6v5u4t3s2"
// }
//
// The IV and auth tag are needed for decryption.
// The key is loaded from environment variables.
// Each encryption generates a unique random IV.Example: Decrypt Configuration from Secure Storage
Retrieve and decrypt encrypted configuration values from a secure key-value store.
// Decrypt node configuration
{
"operation": "decrypt",
"algorithm": "AES-GCM",
"key": "${MASTER_KEY}",
"encoding": "base64",
"property": "payload"
}
// Flow: [Read Config DB] -> [Decrypt] -> [JSON Parse] -> [Apply Config]
//
// From database:
// msg.payload = {
// "iv": "f1e2d3c4b5a6f7e8d9c0b1a2",
// "data": "Qm4kL9pWrT3xH7jN2vF5aY8cZ...",
// "tag": "m3n4o5p6q7r8s9t0"
// }
//
// After decryption:
// msg.payload = '{"apiKey":"sk-abc123","dbHost":"10.0.1.50","dbPass":"s3cur3"}'
//
// After JSON parse:
// msg.payload = {
// "apiKey": "sk-abc123",
// "dbHost": "10.0.1.50",
// "dbPass": "s3cur3"
// }
//
// If the data was tampered with, AES-GCM decryption
// will fail and throw an error (integrity check).Security Best Practices
Do
- Use AES-GCM for authenticated encryption
- Store encryption keys in environment variables
- Use 256-bit keys for maximum security
- Rotate encryption keys periodically
- Let the node generate random IVs automatically
Don't
- Hard-code encryption keys in the flow configuration
- Reuse IVs across different encryptions
- Use AES-CBC without a separate HMAC
- Log or debug decrypted sensitive data
- Store keys and encrypted data in the same location
Common Use Cases
Secure MQTT Transport
Encrypt sensor data before publishing to shared MQTT brokers for end-to-end security.
Secrets Management
Store and retrieve encrypted API keys, passwords, and tokens from databases.
Compliance Requirements
Encrypt personal data (PII) to meet GDPR, HIPAA, or other regulatory requirements.
Secure API Payloads
Add application-level encryption on top of TLS for defense-in-depth security.