Encrypt and decrypt sensitive data in a source

Created by @pavan

This pipeline pattern will encrypt fields passed as JSON docs using a defined transform type (AES), and decrypts and gives back the original message. This pattern is useful for encrypting sensitive messages (credit card info, SSN, patients name, DOB etc).


Within the JSON Generator, replace “Enter certificate here” with your own certificate.

Sources: JSON
Targets: JSON
Snaps used: JSON Generator, Encrypt Field, Mapper, Decrypt Field


Encrypt & Decrypt Fields.slp (9.1 KB)

@pavan Once encrypted, do I need to pass all the information onward? Is it a security risk to do so?

  "key_params":  {
    "passphrase":  {

Yes, the information is needed to correctly decrypt the ciphertext.

No, it’s okay to send the IV in the clear and the rest of the information is used to configure the decryption process.

1 Like

@tstack I have a similar scenario. Please read through the steps.

  1. We are using Encryption & Decryption in 2 seperate ultra pipelines, where first pipeline would encrypt the password field and send this data to second pipeline & the second pipeline would decrypt the data and use it.
  2. The problem is we are giving away key information like Type Of Algorithm, IV, Key_SALT over the internet along with the Ciphertext which is a security concern.
  3. Our design has to have 2 seperate ultra pipelines & not pipeline execute as its an architectural decision.

How can we achieve decrypting the field, without giving away these key attributes?

These values are not secrets, so I don’t think there should be a problem.

Can I ask what is driving the decision to not use PipeExec?


Those give away key information on what stratergy is used by an organization for encryption. Also, the attributes I mentioned are key attributes required for encryption.
These are sensitive data.

Pipeline exec vs Iltra ppipeline decision would take this chain in a different direction. Let’s consider the fact that we need to utilize this Ultra pipelines.

The encryption algorithm in use is not a secret. You can hardcode the algorithm if you want, but it won’t increase security. In some use cases, it can make things less secure since the interface will be stuck with a single algorithm. Then, if that algorithm becomes vulnerable, it will be difficult to change while remaining backwards compatible during the transition period.

No, they are not sensitive. If you don’t want to believe me, please do some of your own research.

Here is a section on IVs in Wikipedia to start:

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret.