2

I used an open-source programming language called Lucee / Cfscript that is closely related to Adobe Coldfusion. The default function that developers use to encrypt and decrypt data (usually for passwords or cookie contents etc) is meant to be compatible with a version of Coldfusion that released in 2002. Given that the algorithm appears to be custom, and not really peer reviewed, and over 20 years old, I'm trying to figure out if it's still safe to use or if legacy code should be updated.

There are a few red flags in the code as far as I can tell.

  • If the key length is 0, it uses a default key "Default Seed".
  • It allows passing in an empty string or null value for the key. This could happen accidentally I'm guessing.
  • If the key is null, you can then decrypt it using an empty string. You can click run on this code to see what I mean. https://trycf.com/gist/06c56b6ec5f95450e32347abc78605aa/lucee5?theme=monokai
  • There is no salt (by default), and iterations is set to 0 (by default).

I don't know enough about encryption to know if my intuition is correct and those are actual red flags. The same logic is used to encrypt and decrypt. The algorithm appears really simple. From limited research, the algorithm implements a form of symmetric key encryption using a series of Linear Feedback Shift Registers. The relevant java code is here: https://github.com/lucee/Lucee/blob/8b37274cf040980f1e179d7604fe9afa088ce21f/core/src/main/java/lucee/runtime/crypt/CFMXCompat.java

It's essentially just three functions, setKey, transformString which calls transformByte over and over.

Is this default encryption still safe to use for storing passwords or basic cookie data or should they be migrated to something else? I'm a software developer not a cryptographer so if the tags on this are inaccurate or anything is missing, please let me know and I'll update. Thanks.

DannyNiu
  • 10,640
  • 2
  • 27
  • 64
ialexander
  • 123
  • 5

1 Answers1

1

No, the algorithm discussed is not secure.

  • It is such that only 4 characters of the key are significant@, which makes key search easy. This is apparent in this loop, and verifiable experimentally: encrypting with key GHIJKLMNOPQR is undone by decrypting with key KLMN. More precisely: if the key is $n>0$ character(s), only characters at offset $4\bmod n\,$, $5\bmod n\,$ , $6\bmod n\,$ and $7\bmod n\,$ from the start are significant. Something slightly different# is documented by this description:

    For the CFMX_COMPAT algorithm, (key is) any combination of any number of characters; used as a seed used to generate a 32-bit encryption key.

  • It's a stream cipher without Initialisation Vector or method to add one (in the two-arguments version), meaning e.g. a single known plaintext/ciphertext pair is enough to decipher anything up to this size.

@ At some point the key is 12-character. I can't tell for sure if the weakening to 4 is deliberate or accidental. Same for apparently using an Alternating Step Generator with three LFSRs, but deviating from and failing short of that if the Java source is faithful (which I didn't check): due to precedence of operators m_LFSR_B quickly gets stationary, and the periods of the other two is shortened.

# If the Lucee / Cfscript language has the same character set as Java, a character would be 16-bit, perhaps increasing the keyspace.

fgrieu
  • 149,326
  • 13
  • 324
  • 622