Encryption Functions

Allows for the encryption and decryption of text data using symmetric AES encryption. This plug-in uses standard Java cryptography functions to expose expression functions for the encryption and decryption of data using AES.

Functions:

  • encryptvalue(): Encrypt plain text data using an AES encryption key stored in the Secure Credentials Store
  • decryptvalue(): Decrypt encrypted text data using an AES encryption key stored in the Secure Credentials Store

Features:

  • Supports up to 256-bit AES keys when JCE Unlimited Strength Jurisdiction Policy is enabled
  • Backwards compatible with older versions of Java lacking support for >128-bit encryption keys
Anonymous
Parents
  • Hi Jussi,

    We are trying to use your plug in for AES 256 bit encryption. Our use case is such that Appian encrypts a value and shares it with external system, and the external system decrypts the value and persists in their data base.

    We noticed that every time we encrypt a value like let's say "123" with the same encryption key the encrypted value keeps changing. Is that normal because the external system is unable to decrypt it? When I am looking online at other encryption/decryption tools, as long as the value we are trying to encrypt and key remain same the encrypted value is also staying constant.

    Any help in this matter is much appreciated.

    Thank you

  • Hi ,

    Good question. The short answer is that this is expected and desirable. Encrypted values (ciphertexts) produced by an encryption mechanism should change with each encryption run, even if the key and input plaintext are constant. Otherwise, someone with access to a list of encrypted values that may contain repeated values could tell the number of times a particular plaintext value appears in the data set, even if they weren't necessarily able to tell what the actual value is.

    A good way to conceptualize why this is not a good idea is encrypting the answer to a sensitive yes/no question. If you have a data set of 5 million users who answered this question, and can find out the answer for one of them, without randomization you can extrapolate that knowledge to decipher all 5 million answers. If you're curious to find out more, this concept is called ciphertext indistinguishability (also sometimes substituted for semantic security), which informally can be described as "an adversary should not be able to acquire any information about the underlying plaintext based on the encrypted value/ciphertext".

    In the underlying code (which is contained in the plug-in JAR), consistent with CBC best practices this is achieved by using a random initialization vector that is saved as part of the encrypted value output. To successfully use the plug-in to encrypt values sent to an external system, you will need to implement the decryption of the value in the external system using the same logic as used in the Java code for decryptvalue().

    Hopefully this clarifies your concern, and thanks for your interest in the plug-in.

    Best,
    Jussi

Comment
  • Hi ,

    Good question. The short answer is that this is expected and desirable. Encrypted values (ciphertexts) produced by an encryption mechanism should change with each encryption run, even if the key and input plaintext are constant. Otherwise, someone with access to a list of encrypted values that may contain repeated values could tell the number of times a particular plaintext value appears in the data set, even if they weren't necessarily able to tell what the actual value is.

    A good way to conceptualize why this is not a good idea is encrypting the answer to a sensitive yes/no question. If you have a data set of 5 million users who answered this question, and can find out the answer for one of them, without randomization you can extrapolate that knowledge to decipher all 5 million answers. If you're curious to find out more, this concept is called ciphertext indistinguishability (also sometimes substituted for semantic security), which informally can be described as "an adversary should not be able to acquire any information about the underlying plaintext based on the encrypted value/ciphertext".

    In the underlying code (which is contained in the plug-in JAR), consistent with CBC best practices this is achieved by using a random initialization vector that is saved as part of the encrypted value output. To successfully use the plug-in to encrypt values sent to an external system, you will need to implement the decryption of the value in the external system using the same logic as used in the Java code for decryptvalue().

    Hopefully this clarifies your concern, and thanks for your interest in the plug-in.

    Best,
    Jussi

Children