Which encryption/decryption algorithm is used in Synology Cloud Sync format 3.0 session key and data encryption?

Question

Background: Based on general information in a whitepaper from Synology, I have reverse engineered the specifics of their Cloud Sync encryption algorithm; see synology-decrypt for details.

In this encryption, both the session key and the data is encrypted using a password, using AES-256 in CBC mode, with key and iv derived from the password as in openssl enc. That problem I've cracked.

Now they upgraded the encrypted file format (from 1.0 to 3.0) to include a random salt, and I'm trying to figure out how that salt is exactly used.

Question: Which algorithm is used to encrypt/decrypt the below plaintext/ciphertext using the given password/salt combinations? (Based on the above, I would expect this to be AES-256 in CBC mode, with key+iv as derived from the password as in openssl enc. But I'm not at all certain.)

Preferably, I'd like to have a UNIX command line (using openssl for example) which transform plaintext to ciphertext or the other way around.

    +--------------------------------------------------------------------+--------------+----------------------+--------------------------------------------------------------+
    |                                    plaintext                       |   password   |       salt           |                          ciphertext                          |
    +--------------------------------------------------------------------+--------------+----------------------+--------------------------------------------------------------+
    | "Just a single line, no newline character at the end..."           | "buJx9/y9fV" | "DXzp4VKu"           | 8f7d757c0e46ab0c434ab72b2a70ec71ad49b2284257189365cb4c706751 |
    | (4a75737420612073696e676c65206c696e652c206e6f206e65776c696e65      |              | (44587a7034564b75 or | 10a3b98bd95f58bd5eafdccb51020354dc33449b221b45c134180882aa84 |
    |  206368617261637465722061742074686520656e642e2e2e)                 |              |  0d7ce9e152ae)       | 739ff78f0213a54a720537785495a84425b0415b                     |
    +--------------------------------------------------------------------+--------------+----------------------+--------------------------------------------------------------+
    | "EA23EB5F36B9008AC73498A8FC53884D1D7EFBA052F902F44B44D40409CBC215" | "buJx9/y9fV" | "DXzp4VKu"           | e866e8c3fb7496d6dd5f0d8befd212e351d3558edf7f097bbe5994b38082 |
    | (454132334542354633364239303038414337333439384138464335333838      |              | (44587a7034564b75 or | 3a6b68a9221dc43c53726b767268c4dfc01f92f99383407070ae5622c10c |
    |  344431443745464241303532463930324634344234344434303430394342      |              |  0d7ce9e152ae)       | 27003cd4d4bcbda1d4bfbe03f5784f5cc45c95b3                     |
    |  43323135)                                                         |              |                      |                                                              |
    +--------------------------------------------------------------------+--------------+----------------------+--------------------------------------------------------------+

(related GitHub issue)

Answer 1

Since all we have to work with here is the term "salt", without actually reverse engineering the new code we can mostly make a few educated guesses.

Usually salt is not a term used in encryption, it is more commonly used in the context of cryptographic hashes. However it's usage resembles IVs in nature: both are randomly generated without requiring the user's awareness, both are used once and aren't shared between users/sessions.

This makes me think one possibility is that the salt is used as the IV, or has some strong relation to it.

Another possibility (which becomes more likely if the password or is derivatives are hashed in some way) is that the salt is actually used as additional input to the hashing function, similarly to how you'd use a salt to avoid cryptographic hash attacks.

Again, without further research and information it would be hard to figure out what's going on there. You'll have to invest some more time in reverse engineering the new version if you'd like to pursue this further.