Hex Encoding and Decoding

Bytes are the computational truth, every other representation is an interface format

Hex-Encoding

Hex encoding is a representation step, not an encryption step. It converts each byte into two ASCII characters in base-16 so binary data can be displayed, logged, or transmitted through text-friendly channels.

The algorithm itself is very simple:

1. For each individual character in the input string, get the ascii decimal value

2. Convert the ascii decimal to base-16 representation

3. Format the base-16 representation such that it has a fixed width of 2, add padding 0 wherever necessary (red highlighted digits as shown above)

4. Append all hex digits to form the final representation

So an (n)-byte input always becomes a (2n)-character hex string.

Hex-Decoding to bytes

Hex decoding does the inverse: two hex characters are mapped back into one raw byte.

The algorithm here is again straight-forward

1. Validate input length is even (hex encodes one byte as two chars).

2. Convert each hex char (0-9, a-f, A-F) into a 4-bit value.

3. Combine nibbles:

4. Append and form the final binary representation. This is our source of truth which can then be converted to any required representation format

Why decode to bytes?

1. Crypto operations are byte algebra, not text algebra

XOR, Hamming distance, block slicing, key scoring, and transposition all work on byte values $[0,255]$, not character glyphs. Treating data as text too early introduces accidental semantics (UTF-8 decoding, null-termination assumptions, locale effects).

2. Not all intermediate values are printable

Many challenge steps, for example when we hex-decode an encrypted string, produce non-printable bytes. If you force them into strings first, you risk corruption or misleading debug output. Byte arrays preserve exact values.