Feature: Throw Warning against invalid Hex input for XOR#2032
Open
RyanChernoff wants to merge 21 commits intogchq:masterfrom
Open
Feature: Throw Warning against invalid Hex input for XOR#2032RyanChernoff wants to merge 21 commits intogchq:masterfrom
RyanChernoff wants to merge 21 commits intogchq:masterfrom
Conversation
…s from key errors
…the key extraction function that an error should be thrown on invalid input.
…character is in the key for XOR with a Hex option
…st for error feature
…berChef into xorKeyValidation
…lter set to false
|
|
C85297
requested changes
Feb 12, 2026
| for (let j = 0; j < data[i].length; j += byteLen) { | ||
| output.push(parseInt(data[i].substr(j, byteLen), 16)); | ||
| const chunk = data[i].substr(j, byteLen); | ||
| if (throwError && /[^a-f\d]/i.test(chunk)) { |
Member
There was a problem hiding this comment.
I'd prefer not to run regex on every hex chunk - this seems inefficient. Could we do a simple ASCII character range check instead?
| for (let j = 0; j < data[i].length; j += byteLen) { | ||
| output.push(parseInt(data[i].substr(j, byteLen), 16)); | ||
| const chunk = data[i].substr(j, byteLen); | ||
| if (throwError && /[^a-f\d]/i.test(chunk)) { |
Member
There was a problem hiding this comment.
This would not support uppercase characters, which are currently supported by the operation. Could you add support for uppercase characters?
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
6 participants
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.
Description:
There was a request for a feature to warn against invalid hex key inputs for XOR (#1918). The current system will simply remove all non-hex characters from the key without informing the user. This can lead to a lot of confusion if mistakes were made when inputting the key. We now added a new field that toggles this filter on and off so that when the filter is off the user will be informed of an invalid characters in their key with an error message.
Resolves #1918
Changes:
src/core/Utils.mjs
Added two new params for (hex only) convertToByteArray: delim and throwError. delim is used to determine what delimiter the fromHex function should use when splitting the input string. We chose to allow this as a parameter since multiple operations use covertToByteArray and it is reasonable to assume that different operations may want to use our new functionality but with a different delimiter. throwError is used to determine whether an error should be thrown if invalid characters are found as we didn’t want to alter the functionality of other functions that relied on convertToByteArray that may have relied on the original functionality.
src/core/lib/Hex.mjs
Added the throwError parameter to the fromHex function to ensure an OperationError is thrown if fromHex is called on a string that contains non-hex characters that are not part of the delimiter.
src/core/operations/XOR.mjs
Added a filterKey field so that existing recipes and other operations that rely on the default functionality of XOR will not be impacted by our changes as it acts as a toggle for our feature. This way the user has the option to choose if they want non-hex characters to be filtered from their keys or not which would make debugging issues similar to #1918 much easier to find.
tests/node/tests/operations.mjs
Added tests that check that an error is thrown against invalid hex keys for XOR with the filterKey field disabled. It also checks that valid keys do not throw errors when the field is disabled.
Testing:
Ran the new test cases along with the previous test file and passed. Changes were also testested on a local grunt development build of the project to verify that UI changes were visible when errors were thrown for invalid keys.
Screenshots:
