fix(crypto): make timingSafeEqual() truly timing-safe

[babiabeo]

The current timingSafeEqual() is not timing-safe and vulnerable to timing based attacks due to its early return on mismatched lengths:

if (a.byteLength !== b.byteLength) return false;

This PR refactors the function to use constant-time comparison.

(Im not sure if there is a way to test this)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.19%. Comparing base (590b165) to head (0bb6075).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6801   +/-   ##
=======================================
  Coverage   94.19%   94.19%           
=======================================
  Files         590      590           
  Lines       42649    42653    +4     
  Branches     6726     6726           
=======================================
+ Hits        40173    40177    +4     
  Misses       2427     2427           
  Partials       49       49           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kt3k]

The current timingSafeEqual() is not timing-safe and vulnerable

Does this mean the length of compared bytes can be detected by changing the input length?

I think the length of the compared bytes can be still detected as lengthMax can be controlled by the attacker's input length

[babiabeo]

The current timingSafeEqual() is not timing-safe and vulnerable

Does this mean the length of compared bytes can be detected by changing the input length?

I think the length of the compared bytes can be still detected as lengthMax can be controlled by the attacker's input length

The main goal isn't to hide the length but to make the comparison constant-time. For example, in a non-timing-safe comparison, when comparing "abc" (the input) with "abcde" (the secret one), it'll immediately return false due to different lengths. The attacker can try other inputs until they find the one taking longer to process.

[babiabeo]

Ok after thinking it over, the early return on mismatched length is totally fine since the length is not secret and it doesn’t leak secret information.

I'll close this PR.