Fix: SHA-512 64-bit arithmetic overflow in Oracle 10g - #4
Open
LuizFelipeBarretoSimoes wants to merge 3 commits into
Open
Fix: SHA-512 64-bit arithmetic overflow in Oracle 10g#4LuizFelipeBarretoSimoes wants to merge 3 commits into
LuizFelipeBarretoSimoes wants to merge 3 commits into
Conversation
Context & BugWhen computing a SHA-512 hash using the as_crypto package in Oracle 10g, the function was returning an incorrect, repeating sequence (7fffffffffffffff...).Root CauseThis issue occurs due to a known limitation in the Oracle 10g mathematical engine. The native bitwise functions (BITAND, BITXOR) and hexadecimal conversion functions (TO_NUMBER, TO_CHAR) handle numbers as signed 63-bit integers ($2^{63}-1$). Since the SHA-512 algorithm relies heavily on 64-bit unsigned integer blocks, the 10g engine was truncating values that exceeded the 63-bit boundary, defaulting to the maximum allowed value (7fffffffffffffff), effectively corrupting the hash.Changes ImplementedTo bypass the 63-bit limitation in Oracle 10g without losing performance, the sha512 function was refactored with custom mathematical helpers:Safe Hex Conversions: Added hex_to_num and num_to_hex helpers to safely convert 64-bit numbers by splitting them into two 32-bit halves.32-bit Chunked Bitwise Operations: Introduced bxor64 and band64 to replace native XOR/AND calls. These functions break 64-bit numbers into High/Low 32-bit chunks, process them safely, and reassemble them.Mathematical Bit Shifting: Replaced the original ror64 and right-shifts with rot_r and shr_safe, which achieve accurate 64-bit shifting and rotating using pure MOD and TRUNC arithmetic instead of native bitwise wrappers.Padding Fix: Ensured the mathematical padding generation properly constructs the exact 128-byte block size required by the SHA-512 specification.Testing & VerificationEnvironment: Oracle 10gInput string: 1234Expected Output: d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d04fba5133e8b1c6e8df59dd3a8ab9d15e3401116318c52Result: Hash computed successfully with accurate values.
Context & Bug
When computing a SHA-512 hash using the as_crypto package in Oracle 10g, the function was returning an incorrect, repeating sequence (7fffffffffffffff...).
Root Cause
This issue occurs due to a known limitation in the Oracle 10g mathematical engine. The native bitwise functions (BITAND, BITXOR) and hexadecimal conversion functions (TO_NUMBER, TO_CHAR) handle numbers as signed 63-bit integers ($2^{63}-1$). Since the SHA-512 algorithm relies heavily on 64-bit unsigned integer blocks, the 10g engine was truncating values that exceeded the 63-bit boundary, defaulting to the maximum allowed value (7fffffffffffffff), effectively corrupting the hash.
Changes Implemented
To bypass the 63-bit limitation in Oracle 10g without losing performance, the sha512 function was refactored with custom mathematical helpers:
Safe Hex Conversions: Added hex_to_num and num_to_hex helpers to safely convert 64-bit numbers by splitting them into two 32-bit halves.
32-bit Chunked Bitwise Operations: Introduced bxor64 and band64 to replace native XOR/AND calls. These functions break 64-bit numbers into High/Low 32-bit chunks, process them safely, and reassemble them.
Mathematical Bit Shifting: Replaced the original ror64 and right-shifts with rot_r and shr_safe, which achieve accurate 64-bit shifting and rotating using pure MOD and TRUNC arithmetic instead of native bitwise wrappers.
Padding Fix: Ensured the mathematical padding generation properly constructs the exact 128-byte block size required by the SHA-512 specification.
Testing & Verification
Environment: Oracle 10g
Input string: 1234
Expected Output: d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d04fba5133e8b1c6e8df59dd3a8ab9d15e3401116318c52
Result: Hash computed successfully with accurate values.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context & Bug$2^{63}-1$ ). Since the SHA-512 algorithm relies heavily on 64-bit unsigned integer blocks, the 10g engine was truncating values that exceeded the 63-bit boundary, defaulting to the maximum allowed value (7fffffffffffffff), effectively corrupting the hash.
When computing a SHA-512 hash using the as_crypto package in Oracle 10g, the function was returning an incorrect, repeating sequence (7fffffffffffffff...).
Root Cause
This issue occurs due to a known limitation in the Oracle 10g mathematical engine. The native bitwise functions (BITAND, BITXOR) and hexadecimal conversion functions (TO_NUMBER, TO_CHAR) handle numbers as signed 63-bit integers (
Changes Implemented
To bypass the 63-bit limitation in Oracle 10g without losing performance, the sha512 function was refactored with custom mathematical helpers:
Safe Hex Conversions: Added hex_to_num and num_to_hex helpers to safely convert 64-bit numbers by splitting them into two 32-bit halves.
32-bit Chunked Bitwise Operations: Introduced bxor64 and band64 to replace native XOR/AND calls. These functions break 64-bit numbers into High/Low 32-bit chunks, process them safely, and reassemble them.
Mathematical Bit Shifting: Replaced the original ror64 and right-shifts with rot_r and shr_safe, which achieve accurate 64-bit shifting and rotating using pure MOD and TRUNC arithmetic instead of native bitwise wrappers.
Padding Fix: Ensured the mathematical padding generation properly constructs the exact 128-byte block size required by the SHA-512 specification.
Testing & Verification
Environment: Oracle 10g
Input string: 1234
Expected Output: d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d04fba5133e8b1c6e8df59dd3a8ab9d15e3401116318c52
Result: Hash computed successfully with accurate values.