Documentation

This large block of commented-out code should be deleted to reduce clutter:

#needs some fix, de-comment this to see.
'''
for idx, char in enumerate(senha): #this is the code i need help. look at the '#string scrambler' to see an better code than this here with same objective.
    for step in range(len(lista[3])):
        if lista[5][step] == 1:
            continue

Alternate versions of code can be stored in you version control system during development.

There is no need for long lines inside a docstring:

This function creates an list (like string) with some caracters of the password, then a code to the password with the list made, which is allways the same for the same password.\n

That line should be shortened by splitting it up into multiple lines.

Many of the lines in the doctring end in literal \n characters which can be deleted:

Then checks to the mode:\n

Simpler

This line:

if debug == True:

is simpler as:

if debug:

This line:

print(f"Password was really wrong.")

is simpler without the f-string:

print("Password was really wrong.")

ruff identifies other similar issues.

Naming

The PEP 8 style guide recommends snake_case for function and variable names.

The function name coddecod is strange. Perhaps code_decode is more meaningful.

The variable reallywrongpassword would be really_wrong_password.

senha does not convey much meaning in English. Either choose a more descriptive name or add a comment to describe what it means. The same is true for other variables like lista, etc.

To restate what has already been said, it is strongly advised to use English for variables, function names etc, and even comments and documentation. Because that makes maintenance easier for others, especially if you work in a team, or you create Github repos and other people find them useful and fork them. This can be challenging, but you have already made that effort in comments.

I find the flow and the code logic cryptic and hard to follow. What does not help is that you have a single function that is quite long, with multiple levels of indentation.

Without even understanding the internals of your code, it is obvious to me that it should be split into two functions, one for encoding, one for decoding. As the old saying goes, one function should do just one thing and do it well. You will surely notice that smaller functions are easier to manage and to debug.

The most problematic in my view is that lista because it is counter-intuitive. Basically, it is a range of parameters, but the purpose of each is not obvious without analyzing the code in depth. Working with indices is tricky and error-prone. There are different data structures that are more convenient to use, for example a class, a dataclass or even a named tuple.

Regarding the debug mode, you should get acquainted with the logging module, then instead of print just use logging.debug. So that your debug messages will show up depending on the requested logging level (can be set via a command line parameter or config file). Think of it, you have plenty of if debug == True: in your code, and you could easily get rid of them.

Apart from all of the other good points raised, you would also want to guard the calling of your test code at the end of the program.

if __name__ == '__main__':
    test = coddecod("FeijaoTropeiro", "Elias", "c")
    wrong = coddecod("54hvrvrwe4ij", test)
    wrong2 = coddecod("Feijao", test, "d")
    right = coddecod("FeijaoTropeiro", test, "d")
    
    print(f"""The text is: 'Elias'.
This is the message encrypted: {test}
These 2 are the outcomes with wrong passwords: '{wrong}' and '{wrong2}'.
This is the message with the right password: {right}.
Run this code more times to see the encrypted message change.""")

This allows you to import the module containing coddecod into another program without executing this code.

What is Entropy?

Who is Eve?

John Gordon explains that

over the years Alice and Bob have tried to defraud insurance companies, they've played poker for high stakes by mail, and they've exchanged secret messages over tapped telephones. ...

Now most people in Alice's position would give up. Not Alice. She has courage which can only be described as awesome. Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn't trust, whom she cannot hear clearly, and who is probably someone else, to fiddle her tax returns and to organize a coup d'etat, while at the same time minimizing the cost of the phone call.

And Eve is the eavesdropper who tries to listen in on Alice's conversation.

Or in the context of encrypted archival file storage, we might model communication across time as "week ago Alice" sending a message to "current Alice". In the intervening week or so, she forgot the plaintext but not the key.

standards

When I speak of the Advanced Encryption Standard in this article, I refer exclusively to the AES-256 variant.

entropy

By hypothesis Eve sees the ciphertext and the encryption algorithm, but not the secret key. Eve wants to read the cleartext.

Alice wants Eve's task to be as hard as possible, requiring a brute force search of the key space. Let's drill down on that.

Suppose Alice is using encryption software which allows her to choose from exactly two valid passwords: {yes, no}. Eve knows this. If Alice chooses a 3-character password, is that somehow "more secure" than a 2-character password? No.

Eve does trivial work to read the cleartext -- just try both passwords. If she sees gibberish then she knows to try the other one. We assume Alice didn't send random bits; there's usually some recognizable structure to the cleartext, such as being composed of words from a dictionary.

We could slightly improve matters by accepting
{vermelho, verde, azul} as the valid passwords, but then we'd have only a little more than one bit of entropy. If we accept
{vermelho, verde, azul, branco} then we have two bits of entropy. Accepting from the set of Snow White and her seven dwarves would give us three bits of entropy, and so on.

password

For the moment I will interpret "password" literally -- a word that appears in Webster's dictionary or similar.

If chosen by a ten-year old, having a vocabulary of likely less than eight thousand words, we might have \$13\$ bits of entropy, so Eve must do about \$2^{13}\$ work. (Or half that, but let's not quibble just yet.)

By the time that student graduates high school they might have doubled their vocabulary to ballpark sixteen thousand words, so Eve does \$2^{14}\$ work. Even after years of graduate work we might see just another doubling, so Eve does \$2^{15}\$ work.

Let's be generous and say that Alice randomly chooses each word from a hefty dictionary, having sixty-four thousand words, for two random bytes and \$2^{16}\$ work. In many crypto systems Eve could still brute force through all those possibilities within one minute or even one second. Some systems, such as Argon2id, are specifically designed to be slow, so Eve might take hours or years to try all possibilities, even with many machines at her disposal.

passphrase

Sometimes documentation or software identifiers mention a "password" when really a "passphrase" is intended. We will assume there is no practical length limit, so a sentence or even a paragraph could be used.

Under the charitable assumptions we've made so far, how much work must Eve do? Frankly, not much.

• 1 word: 16 bits
• 2 words: 32 bits
• 3 words: 48 bits
• 4 words: 64 bits

We'd need more than three words before life starts getting difficult for Eve, and even then we need unrelated words. So "call me Ishmael" would be a poor choice, offering far less than 48 bits of entropy.

hashing

In a short dictionary that begins with these words, we might assign 1, 2, 3 to {a, add, act}. And then "zebra" is up in the thousands somewhere.

So the 256-bit AES key might be filled with 0x0003 for "act", followed by 0x0002 for "add", followed by another number for the rank order of "zebra". But we'd still need sixteen dictionary words to fill up the AES key. Or we could leave a bunch of zero bits at the end.

And suppose our (weak!) passphrase started, "It was the best of times". Dickens is a bit prolix, so we might wind up with more than sixteen words. What to do?

Hash functions to the rescue! We could run the phrase through SHA1, same as git. But that only gives us 160 bits. More convenient to run it through SHA3-256, which gives us just what we need.

The remarkable thing about the Diffusion and Confusion avalanches of such a hash is that small amounts of entropy (like R,G,B color name) will be preserved, while inputs with more than 256 bits of entropy will produce an output having 256 bits of entropy. (Well, there are some details we needn't pursue here, like hash of hash may behave subtly differently from a naïve expectation.)

Also, flipping a single bit in the input will flip about half the output bits. Hash of uppercase "It was" starts b2dc0d88, while hash of lowercase "it was" starts fff4c217. The inputs look similar, while the outputs look very different.

PBKDF

In summary, the trouble with "a passphrase I can memorize" is that it likely has far fewer than 256 bits of entropy.

There's at least two ways to cope with this. One is to use a memorized password to unlock a "vault" file containing the "real" 256-bit key. In the same vein we might store those key bits on a thumb drive, biometric ring, or similar storage that is secure from Eve and perhaps even from her evil friend Mallory.

Another way is to give up and say the memorized password is all we have, so let's make the most of it. If our weak passphrase is "red tomato", we could use a fast SHA3 hash to smear that handful of entropy across 256 bits. But better to use the slow Argon2id hash function. Why? Because it has been engineered to require that Eve purchase lots of CPU and lots of memory if she wants to have a farm spend time doing brute force guessing. It's not the only such password based key derivation function, but it is the winner of the Password Hashing Competition.

OP entropy

The OP code does not in fact use senha, so describing the actual entropy used is moot.

range()

    for _ in range(5):
        lista[3].append(lista[0][0 + step: 17 + step])
        step += 17

To compute that constant list of str, you might prefer to supply a 3rd step argument.

    for i in range(0, 5*17, 17):
        lista[3].append(lista[0][i : i+17])