v1.0.797

Description

What

• Adds hmacSha512 (proper HMAC-SHA512 via RFC 2104) to utils.ts and updates getFileHmacFromShardHashes to use it instead of the previous SHA512(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 computeHmac into NetworkFacade's cryptoLib so the SDK computes and sends an HMAC-SHA512 in the finishUpload payload 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/sdk to 1.17.9 which exposes computeHmac in the Crypto interface and threads it through finishUpload/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

• #1997

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