Commit b4b6d76
committed
fix: gmpToBytes no longer falls into the PHP "0" Elvis-falsy trap
For FF1 values where gmp_strval($val, 16) produced exactly "30", the
prior `hex2bin($hex) ?: "\x00"` would round-trip the bytes through
ASCII text. The result, the single byte 0x30, equals the string "0" —
one of PHP's handful of falsy strings — so the Elvis operator silently
swapped it for NUL.
The bug fired any time a half-block's integer value happened to equal
48 and gmpToBytes was asked for a fixed-width byte string. In FF1 that
shows up in the Q block, corrupting one round's PRF input and every
round after. The output stayed self-consistent (encrypt/decrypt are
still inverses) so a roundtrip test passed; only a cross-language
comparison surfaced it.
The cyphera adversarial FF1 b-matrix (radix 10, length 6, plaintext
'307418', case 22) hit it on round 5 of encryption: B = [0,4,8] →
num(B) = 48 → numB silently became 0x0000 instead of 0x0030, and
the ciphertext diverged from every other Cyphera SDK.
Fixed by switching to gmp_export with explicit byte-order flags, so
the path never goes through PHP's loose-typing.1 parent 29e465e commit b4b6d76
1 file changed
Lines changed: 7 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
170 | 170 | | |
171 | 171 | | |
172 | 172 | | |
173 | | - | |
174 | | - | |
175 | | - | |
| 173 | + | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
176 | 179 | | |
177 | | - | |
| 180 | + | |
178 | 181 | | |
179 | 182 | | |
180 | 183 | | |
| |||
0 commit comments