How effective is this encryption?

[huntson]

You said one of your goals was to determine how safe the files are that are encrypted. Can you offer you opinion on this please?

[stevesbrain]

Sadly @huntson I think this is a dead repo. No activity for 2 years, and no comments on issues from last year :(

[marnix]

@stevesbrain Not a dead repo, just the occasional spike, every year or so. That's all I can manage usually... :-)

[marnix]

@huntson My current opinion is that this encryption seems fairly weak, and it is weakened by the way a Synology NAS uses it.

I mean, the encryption algorithms themselves look fine, and the version 3.0 algorithm seems to have improved them slightly by using a salt for the password encryption of the 'session key'.

First, since the encryption is per-file without changing file names, if the encrypted upload also contains a file with known contents (e.g., an empty file, a well-known icon, or even a specific pirated movie) then a known-plaintext attack could perhaps be used to retrieve the random session key for that file, and use it to help derive the password or private key.

But worse, an encrypted file seems to contain way too much information about the random 'session key' that is used for that specific file: Not only is it present in password-encrypted or public-key-encrypted form, but there is also a hash of the session key, and even a hash of the password or the private key itself!

That means that e.g. for a password-encrypted file, to guess its password it is sufficient to take the MD5 hash of the first 10 bytes of key1_hash followed by the password guess, and compare it to the rest of key1_hash! So it is basically trivial to do a dictionary attack on the password.

Combine all of that with the fact that a Synology NAS seems to only let you use the same password or key pair across all files in an encrypted upload, so if you crack it for one file you cracked it for all!

Based on that, I'm currently not using this feature of my Synology NAS. :-)

[adrw]

@marnix Thanks for opining, a lot I didn't know about the vulnerabilities of my NAS encryption!

[rbrown256]

Many thanks for your analysis. I have a few queries if you're still interested in this project, but I guess not since it has been a few years.

then a known-plaintext attack could perhaps be used to retrieve the random session key for that file, and use it to help derive the password or private key.

I guess you're referring to version 1 here? As I see in the code, the salt isn't introduced by Synology until version['major'] > 1.

If using a version greater than 1, the code derives an IV from the password and salt, where the salt is a unique value saved in the keypairs available in each file when above this version number.

Different IVs will mitigate a known plaintext attack. Therefore, this is no longer an issue if you're not using v1?

But worse, an encrypted file seems to contain way too much information about the random 'session key' that is used for that specific file: Not only is it present in password-encrypted or public-key-encrypted form, but there is also a hash of the session key, and even a hash of the password or the private key itself!

I gather what you're saying here is that there's no key stretching applied? [edit - just checked again and I see the code does 1000 iterations on the password and salt, so there is some key stretching, although low by today's standards - again, this only happens above v1]

So with my 30+ character password, I can mitigate this vulnerability because that isn't vulnerable to a dictionary attack.

If my above assertions are correct, once we're at or above version 2 where we have a "salt", then Synology's approach is fine given sufficient entropy in the password (e.g. 128 bits).

Having said all that, I'm tempted to go with Rclone instead anyway, since this is fully open source.

Again, thanks for this project. I managed to get your code working thanks to the implementation here