Understanding Encryption length calculation and rounds

Question

I am trying to learn about password encryption by creating a simple password hashing algorithm, although many online articles did warn "Do not create your own algorithm".

I discovered that most of the encryption outputs are represented in bits instead of characters. Initially, I misunderstood this, how bits should be used instead of characters--resulting in my creation of an algorithm with a 1024-character output.

Why is encryption always represented in bits instead of characters? If I encrypt a color hexadecimal value (e.g. red with hex value ff0000), and at the end my output still contains value 0-9,a-f with 128 characters in total length, this will be represented as 512 bits since hexadecimal only uses 4 bits, as 512bits/4=128 characters. Have I understood this correctly?

Do the rounds in encryption mean the same thing as the number of iterations of my encryption process (e.g. transposition, mirroring, etc.)? And how should I determine the number of rounds that I should use to make my algorithm strong against attack?

Answer 1

Computers operate on bits and bytes internally. They do not operate on (hexadecimal) characters. Characters are for human consumption.

Hexadecimals use only 4 bits out of a possible 8 in each byte, assuming 8 bit ASCII or compatible encoding. To perform any calculation such as bit shifting, addition or modular multiplication, you'd first have to convert the characters to bits. So that's not something you would perform internally to your hash function. Only if you want to make your output compatible for human readable text do you need to convert to hexadecimals (or base 64 or any other encoding of binary in text).

A color consists of 3 bytes in the common RGB scheme. That they are represented as three concatenated hexadecimal bytes is again only for human consumption. If you look at the contents of a bitmap file (.bmp) then certainly the dots / pixels are not present as hexadecimal characters. They are bits and bytes.

---

A block cipher and secure hash (not password hash) uses a certain number of rounds to be secure. How many rounds depends on the complexity of the inner function; some algorithms have a lot of simple rounds and some have fewer complex rounds. You probably want to have at least some 30% of headroom against the best known attacks to your function (i.e. if 7 out of 10 rounds are broken then you'd consider your function secure, if 9 out of 10 are broken then you're living too close to the knife's edge).

Yes, the number of iterations is similar to the number of rounds in functionality. However, commonly each iteration in a password hash would already create a secure result if the input password has enough entropy. That is, you would at least not be able to reverse the function and gain information about the input. Instead, the number of iterations should be as large as possible so that an adversary has to perform a lot of work (the work factor) to brute force a large amount of password hashes.