You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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 d330f61 - 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.
The text was updated successfully, but these errors were encountered:
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:
duplicacy/src/duplicacy_chunk.go
Lines 216 to 218 in f2d6de3
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 d330f61 - 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.
The text was updated successfully, but these errors were encountered: