Description
What
- Adds
hmacSha512(proper HMAC-SHA512 via RFC 2104) toutils.tsand updatesgetFileHmacFromShardHashesto use it instead of the previousSHA512(key || data)concatenation - Derives a dedicated HMAC key via
HKDF(fileKey, info="for hmac", 512 bits)to enforce cryptographic key separation between the AES-256-CTR encryption key and the HMAC-SHA512 authentication key - Wires
computeHmacintoNetworkFacade'scryptoLibso the SDK computes and sends an HMAC-SHA512 in thefinishUploadpayload during every upload - Fixes the download verification path to convert SHA256 shard hashes to RIPEMD160 before computing the HMAC, matching the shard hash format stored by the bridge
- Bumps
@internxt/sdkto1.17.9which exposescomputeHmacin theCryptointerface and threads it throughfinishUpload/finishMultipartUpload
Why
Files uploaded to the bridge are encrypted client-side. Without an HMAC, a compromised server could substitute shard content and the client would silently decrypt garbage. The HMAC binds the encrypted shard (via its RIPEMD160(SHA256) hash, the same identifier the bridge stores) to the file key, so only a client that holds the key could have produced it. Using proper HMAC-SHA512 instead of SHA512(key || data) eliminates the length extension vulnerability present in the previous construction.
Regarding the HMAC key: using the same key for both encryption and authentication violates the cryptographic principle of key separation; HKDF ensures the two keys are independent even though they share the same origin.
Related Issues
None
Related Pull Requests
Checklist
- Changes have been tested locally.
- Unit tests have been written or updated as necessary.
- The code adheres to the repository's coding standards.
- Relevant documentation has been added or updated.
- No new warnings or errors have been introduced.
- SonarCloud issues have been reviewed and addressed.
- QA Passed
Testing Process
Specified on the Jira related ticket.
Additional Notes
None