Repository navigation
Equal hashes on non-equal JS strings are dangerous to the ecosystem #60267
Description
Instead, anything in crypto module accepting JS strings should verify that the strings are well-formed before converting them to Buffers, and throw
In before: the argument that those strings would be treated as equal in other contexts is not valid
E.g., using bn.js@4:
import BN from 'bn.js' // 4
import { hash } from 'node:crypto'
const [a, b] = JSON.parse(payload) // user input
console.log('Hashes equal?', hash('sha256', a) === hash('sha256', b))
console.log('Strings equal?', a === b)
console.log('bn.js values:', (new BN(a)).toNumber(), (new BN(b)).toNumber())Output:
Hashes equal? true
Strings equal? false
bn.js values: 55229 57036
If anything anywhere uses string hashes for any purpose like k/nonce calculation (ref: GHSA-vjh7-7g9h-fjfh), e.g. in curve cryptography or in a block/stream cipher, this can lead to private key/data exposure
Also obviously it allows to do things like this:
import { hash } from 'node:crypto'
const [a, b, c, d] = JSON.parse(payload) // user input
const sha256 = (x) => hash('sha256', x)
console.log('a === b?', sha256(a) === sha256(b))
console.log('c === d?', sha256(c) === sha256(d))
console.log('a + c === b + d?', sha256(a + c) === sha256(b + d))a === b? true
c === d? true
a + c === b + d? false
As a solution, enforce usage of String.prototype.isWellFormed on all string input and throw
Obviously, also applicable to sign/verify and other APIs:
import { generateKeyPairSync, createSign, createVerify } from 'node:crypto'
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 })
const [a, b] = JSON.parse(payload) // user input
const sign = createSign('SHA256')
sign.update(a)
sign.end()
const signature = sign.sign(privateKey)
const verify = createVerify('SHA256')
verify.update(b)
verify.end()
console.log('types:', typeof a, typeof b)
console.log('verified?', verify.verify(publicKey, signature))
console.log('a === b?', a === b)types: string string
verified? true
a === b? false
WebCrypto is not affected as it doesn't accept strings
Node.js accepts JS strings but operates on byte arrays, and js-string-to-byte-array transform is not injective
There should be a safeguard against transform collisions
Activity
ChALkeR commentedon Oct 15, 2025
cc @nodejs/security / @nodejs/security-wg for discussion
Renegade334 commentedon Oct 15, 2025
This feels like another flavour of the caveats already offered regarding strings and the crypto API (#37248)? Those do separately mention both the behaviour of invalid code points when converted to UTF-8 and the risks from Unicode behaviour when passing user input, although doesn't currently have a specific warning for the intersection of those two as applied to using non-well-formed strings as input.
ChALkeR commentedon Oct 15, 2025
Yes, I don't expect that this is something novel, hence not a security report
My argument is that throwing on non well formed strings would be much safer / expected behavior than essentially replacing them with other strings prior to hashing
Signing one string and getting
truewhen verifying a non-equal string against the signature is problematicMatching hashes on non-equal strings are problematic
And those could come from user input via
JSON.parsegithub-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.