Security issue in encryption key derivation?

I was trying to understand the encryption code in duplicacy and its handling of the many keys stored in the config file when I discovered something unexpected here:

https://github.com/gilbertchen/duplicacy/blob/f2d6de3fff7567740e86cb49801b0698f085cc59/src/duplicacy_chunk.go#L216-L218

For some reason this code is using the 'derivation key', which for things like snapshots is just a plaintext file path, as the secret key for Blake2b, and then digesting the encryptionKey to get the combined key. I would have expected the opposite, using the encryptionKey as the secret key for Blake2b, and then digesting the path. Indeed the wiki page on encryption here https://github.com/gilbertchen/duplicacy/wiki/Encryption states:

"The snapshot is encrypted by AES-GCM too, using an encrypt key that is the HMAC-SHA256 of the file path with the File Key as the secret key."

Which is precisely the opposite of what the code actually does. Worse, it looks like this may have led to issues in the past, specifically this commit https://github.com/gilbertchen/duplicacy/commit/d330f61d251f12c24cdd38b77d143cbb716913da - which would never have been an issue if the construction wasn't backwards.

I am not sure how exploitable this is, I hope it isn't, but it's a pretty big code smell in the middle of the encryption code.

gilbertchen / duplicacy

Security issue in encryption key derivation? #638