Someone created an issue on GitHub asking about the way some encryption keys are derived: Security issue in encryption key derivation? · Issue #638 · gilbertchen/duplicacy · GitHub
Is this a real problem? Are there any security implications here?
Thanks for posting this. I saw the original issue when it was posted and I was hoping for some follow up.
Looking at the code myself, I think this isn’t an issue. I think the derivationKey is indeed a “plaintext file path”, but I think the file path in question is the path of the chunk in storage, which is the encrypted hash of the chunk. So, while it is indeed visible, it’s not exactly a vulnerability as it’s intended to be visible to enable the convergent encryption / chunk deduplication strategy Duplicacy uses.
So, that’s my hot take after a few minutes reading over the code, but I wouldn’t take any of it as a final word. If what I wrote is accurate, maybe the description could be updated to clarify the algorithm.
I want to re-stress how unsure I am… 
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 Encryption · gilbertchen/duplicacy Wiki · GitHub states:
The secret key of a Keyed Hasher isn’t handled differently than the content to be encrypted. Instead, it is supplied to the hasher right after the hasher has just been initialized. So, it is a matter of which one should be hashed first, the derivation key or the encryption key. I would argue that hashing the derivation key is actually more secure, because the derivation key changes every time but the encryption key remains the same. This makes it a little bit harder to brute force the encryption key.
1 Like