When does a hexidecimal number pivot to letters rather than numbers - encryption

Assume this number 173250103518582539668252657343418508842, if I wanted to convert it to a hexadecimal number such that a 10 = F, 11 = E, etc. where are the breaks/how does that work?
I've done a bit of research online and I can't seem to find the answer. It's a really low-level question, I know.
6 characters in there's a 10, would that be flipped to an F or would that get missed because whatever triggers the flip in the int -> string hexadecimal conversion happens another way?

Hexadecimal is an encoding used to express binary data in base-16 where the ascending sequence is 0-9a-f (upper or lower case a-f), once character per 4-bits (4-bits has 16 possible values). Thus 2 hex characters per byte.
binary bits (msb on left) and hexadecimal:
0000 0
0001 1
0010 2
0011 3
...
1001 9
1010 a
...
1111 f
To say "10 = F, 11 = E" is not hexadecimal.
To encode the decimal number 173250103518582539668252657343418508842 convert it is a Big Integer and then hexadecimal encode the underlying bytes to hexadecimal.
or
To encode the ASCI string "173250103518582539668252657343418508842" to hexadecimal convert each letter to the underlying ASCII binary code and then encode that into hexadecimal: "313733323530313033353138353832353339363638323532363537333433343138353038383432".
See Hexadecimal and ASCII.
Aside: My first day as a programmer I had to know hex, binary and ASCII encoding, funny how things change.

Related

How to convert hex code to decimal code or vice versa

How can I know what these bunch of hex code means?
02 00 A0 E3 1E FF 2F E1
Any convertor of these codes to decimal code like 1,2,3 etc or vice versa like deciaml code to this type of hex code?
Thanks
This is my first response in stack overflow. So here goes...
What Hex Code (a.k.a. hexadecimal) represents purely depends on its context, or what does it mean to the program or machine. It could be a string, machine code (assembly language), flags, pointers to memory, data, part of an image or whatever. And this is dependent on the processor where this code is located also.
Each 2-digit hex code is a byte and represents decimal number (0-255 or 00-FF), half of a byte or 1 digit hex code is called a nibble.
Converting Hex Code to decimal is trivial. Convert from decimal to hex, not as trivial.
There are many calculators that have this functionality built in.
0-9 => 0 – 9, A=10, B=11, C=12, D=13, E=14, F=15.
Now, if you want to convert a 2 digit number like 12 hex (i.e. 0x12 or 12h ). Here is the formula.
(16 x 1) + (1 x 2) = 18 (decimal)
A four-digit hexadecimal 4A3E =>
(4096 x 4) + (256 x 10) + (16 x 3) + (1 x 14) = 19006 (decimal)
An integer in C# is 4 bytes, so your example hex code could also represent 2 integers in C#. Or it could be simply 1 number in C# called a “long” which is 8 bytes and could represent a number between:
0 to 18,446,744,073,709,551,615 unsigned long OR
-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 signed long
Also something to note hex code also represent characters called ASCII (pronounced a·skee) This is an internal mapping within the microprocessor and could be different. 00 is not mapped so it typically means the end of the string.
Hex codes like that could represent a binary number. You could paste "0200A0E31EFF2FE1" into a converter like this to find out that the decimal representation of that number is "144292085413916641", for example.
But, from the way that your hex codes are grouped, it appears that you're looking at binary data, rather than a single integer that's represented in hexadecimal. When hex codes are grouped in pairs, each group of two characters represents one byte. https://en.wikipedia.org/wiki/Hexadecimal#Written_representation

Base32 alphabet that is an overlapping superset of hexadecimal? (math/CS)

This is maybe more of a math question, but I'm stumped on it:
Let's say I have an 8-digit hex string. That can represent values from 0 to 2^32-1. Now let's say I want to have an 8-digit string of another base like base32. Is it possible to construct an alphabet for base32 (or another base) that is a strict superset of hexadecimal so that any hex string below 2^32-1 will decode via base32 to the same value and only larger values >=2^32 start incorporating base32 characters outside the hex range?
In other words is it possible to "upgrade" from base 16 to a higher numbered base in a way that is backward compatible with hex identifiers?
You can assign numbers to 8-character strings however you like.
There are 232 8-character hex strings, to which you can certainly assign their hex values.
There are 240 8-character strings with characters in, say, 0123456789ABCDEFGHJKMNPQRSTUVWXY. 232 are hex strings, and the remaining 240 - 232 strings can be assigned any numbers you like.
You won't be able to assign them numbers via a "normal" decimal-like system, however, because hex requres "10" to be 16, not 32. There are ways that aren't that hard, however. For example, given a 40-bit number:
Convert the lower 32-bits to 8 character HEX.
Assign one of the remaining bits to each character, and for each one bit, add 'G' to the corresponding character, changing its range from '0-F' to 'G-Y'
Now you have a string for each 40-bit number, and the smaller ones have the same strings as their hex representations.
I am not sure if I understand you right; please correct me if I am wrong. Anyway:
A hex digit (base 16) is represented by 4 bits. Its range is 0000 … 1111, representing digits 0 … F.
An 8-digit hex string is thus represented by 32 bits, that can represent values from 0 to 2^32-1. Its range is 00000000 … FFFFFFFF.
Lets consider a base 17 system, called here a 17dec system.
A 17dec digit (base 17) is represented by 5 bits. Its range is 00000 … 11111, representing digits 0 … V (using a standard Latin alphabet).
A 8-digit 17dec string is thus represented by 40 bits, that can represent values from 0 to 2^40-1. Its range is 00000000 … VVVVVVVV.
Thus, hex and 17dec cover the same bit combinations from 0 to 2^32-1. It is thus not possible to have a number system with a higher base that is bit-wise compatible with a lower base system.
Take, e.g. the value 10000.
The hex representation of 10000 is 10.
The 17dec representation of 10000 is G.
There is no way to make this compatible.

Using Hexadecimal to represent a 7 bit code

My computer uses ASCII, American Standard Code for Information Exchange.
It is my understanding that this uses a 7 bit code to represent all the letters, symbols, and numbers needed for the english language.
It is my understanding that these 7 bits can be represented with hexadecimal codes.
I thought that hexadecimal needed 8 bits. 4 bits per number.
Can some one explain to me how the hexadecimal system can be used to represent the codes in the 7 bit ASCII system.
Thanks in advance.
Hexadecimal numbers don't need eight bits, each hex digit can represent four bits but there's no upper limit, since you can just use more digits:
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffff...
For representing seven-bit values, you can just use the lower half of the eight-bit hex numbers, 0x00 through 0x7f.
That gives you the binary numbers 0000000 through 1111111.
With 7 bits you can represent every number from 0 to 2^7 = 127 (decimal) = 7f (hexadecimal).
Hexadecimal doesn't need 7 bits, it is just another way to write numbers.
You can combine any combination of up to 4 bits into one hexadecimal character.
1 bit: 0 to 1
2 bits: 0 to 3
3 bits: 0 to 7
4 bits: 0 to F
For 7 bits you need 2 hex digit, one coding 3 bits and the other 4 bits so you get a code of 00 to 7F.
Or you use 8 bits, but the most significant bit is always 0.

How can I quickly compress a short hex string and decompress it in c#

I have some 16 character hex strings like this:
B5A43BC5BDCEEFC6
2C7C27F05A488897
1514F4EC47C2EBF6
D91ED66BC999EB64
I want to shorten them and have the shortened string only contain upper case letters.
DeflateStream and GZipStream just increase the length.
Anyone can help me shorten these 16 characters hex string to 6 characters or fewer?
Alternatively, shortening a 32 character hex string to 12 characters or fewer is okay.
Unless there is some redundancy in your 16 hexadecimal character input, what you are asking is mathematically impossible. You can prove this by examining the entropy of your inputs.
You have 16 hexadecimal characters.
16^16 = 18446744073709551616 ≈ 1.84x10^19 possible values.
You want the string to be 6 upper (or lower - the maths is the same) case characters or fewer. In English (I assume you want English) there are 26 uppercase characters.
26^6 = 308915776 ≈ 3.09x10^8 possible values.
To guarantee that you can represent every one of your 16 hexadecimal characters, you need 14 upper (or lower) case letters.
13 characters isn't enough:
26^13 = 2481152873203736575 ≈ 2.48x10^18 possible values.
14 characters will suffice:
26^14 = 64509974703297150976 ≈ 6.45x10^19 possible values.
The only way you could possibly do it (assuming no redundancy) in six (or fewer) characters is to have some base where each character has 1626 possible values.
1626^6 = 18480905552168525376 ≈ 1.849x10^19 possible values.
Shortening 32 hexadecimal characters to 12 or fewer upper (or lower) case characters is impossible by the same logic. Without redundancy, you can't guarantee that you can shorten any arbitrary 16 (or 32) hexadecimal characters into 6 (or 12) upper (or lower) case characters.
You can convert hexadecimal number to a higher base like sexagesimal:
Quickest way to convert a base 10 number to any base in .NET?

How do I Base64 encode a 2 byte sequence?

I'm given a 2 byte sequence and asked to Base64 encode it:
00000001 00010001
From what I understand you can only encode sequences of 6 bits when working with Base64.
So because 16 bits is not divisible by 6 I'm a little stuck.
The solution I can see is to convert the given 2 byte sequence into a 3 byte sequence so it becomes divisible by 6. But how do I do this without changing the value of the initial sequence?
Basically, you pad it out with zeroes to the next multiple of 6 bits, and pad out the last four-character sequence with =s. Since the last two zero bytes don't make up a full input byte, the decoder knows to ignore them. (The = padding isn't totally necessary, but it's customary to make the end result always a multiple of 4 characters long.)
For instance, the sequence you've got is:
00000001 00010001
Breaking that up into groups of 6, we get:
000000 010001 0001
Pad with zeroes:
000000 010001 000100
Convert to ASCII:
ARE
And pad that out:
ARE=

Resources