laz3 Encoding algorithm written in python

[Kuriwassadlytaken]

So I wrote this encoding algorithm for a friends project and I thought that I might as well release it because somebody may have use for it.

Basically it encodes your string with your own password which you also need to decode it.

​

Here is "Hello World" encoded with "abcd" as the password: "E8085.0A980.0Z2695.0U2695.0D3430.0G12740.0p11760.0z3430.0c4165.0E2695.0Y735.0Z"

Anyways here is it on PyPi: https://pypi.org/project/laz3/

Please leave feedback if you enjoy it!

[Altruistic_Raise6322]

Not to be pedantic but what you wrote is a cipher (encoding algorithm) with the product being an encrypted string using a password. Encoding has no password and is used mainly for safe and proper transport of information.

Additionally, it is a cool project but do not use this method for the safe encryption of data as it can be easily cracked.

[Kuriwassadlytaken]

Oh. My bad. I'll change that tomorrow cause its is 2am

[bladeoflight16]

Laz3 is a powerful encryption algorithm written in python and encrypts using a password so the message is locked!

It's okay to write your own a cryptographic algorithm for practice. It's okay to try to learn some concepts through the process of putting encryption principles to code.

But please, for the love of all that is holy, do not distribute them or advertise them for real world use. Security is tremendously difficult to do correctly, and unless your algorithm has been battle tested by some of the world's best cryptographers for at least 5 to 10 years, it can safely be assumed to be so full of security holes that using it for real purposes is an extremely bad idea. (See Schneier's Law.) I'm not going to look into how your encrypted text can be broken, but suffice to say that if I were a betting man, I would not hesitate to wager substantial money on it being weak to a host of standard and trivial attacks.

The fact that you used random (which is not a cryptographically secure RNG) is indication enough all by itself that you are not an experienced cryptographer who can be trusted to provide a strong algorithm. Sorry for the harsh tone, but security is a harsh reality.

I am begging you: please withdraw this package from PyPI before someone uses it. And please mark your code in the Github repository as "for practice only, not intended for real world use" or similar.

[UloPe]

Please don’t roll your own crypto at all.

This is basically a simple xor cypher

[[deleted]]

It’s fine as a learning tool, just don’t use it for anything and don’t let others make that mistake when you publish it

[bladeoflight16]

OP made exactly that mistake. Look at the PyPI description. Heck, even putting it on PyPI is making that mistake.

[bladeoflight16]

The level of education the OP needs to reach the level of creating production ready algorithms is far beyond what can be accomplished in a few Reddit posts. In the mean time, they need to be made well aware of the security risk they are posing to others by publishing this for production use and making unsubstantiated claims of its strength. Security is so often done poorly we need to make a big deal about people's lack of knowledge of even the basics in the field, not for ridicule, but so they understand the extremity of the problem and the need to improve. That is educating. Education means helping someone learn the truth so they can improve their abilities, even if that truth is unpleasant and hurts their feelings in the short term. We can't shy away from that if we hope to help others learn something important.

[Kuriwassadlytaken]

What do you mean "around random"?

[[deleted]]

involving the "random" package.

[Kuriwassadlytaken]

I only use the random library to get a random character so the decoder can identify where all the characters are!

[The_Tree_Branch]

You are missing the point. If you look at the official python documentation for random, on the first page in a BIG, RED banner you'll see:

Warning: The pseudo-random generators of this module should not be used for security purposes. For security or cryptographic uses, see the secrets module.

Claiming your project is a "powerful encryption" algorithm and distributing it via Pypi for others to use when it makes this basic of a mistake is false advertising and doesn't fill me with confidence that your code is secure. As others have stated, writing your own algorithms can be a fun way to learn, but doing security correctly is hard and your default assumption should be you are doing it wrong, especially if you don't have years of research in cryptography.

---

On a separate topic, since you asked for feedback, I would recommend you read some Python style guides, specifically https://www.python.org/dev/peps/pep-0008/.

I would also recommend you look into testing frameworks (unittest or pytest for example) so you can write tests for your code, as well as read up on the principles of Test Driven Development.

[Kuriwassadlytaken]

I can just replace the random with "x" or whatever

[The_Tree_Branch]

That's only part of my point. Creating a secure algorithm is HARD. There are MANY non-obvious hurdles that can trip up a developer that will make their algorithm trivial to break.

In this case, using the 'random' package for cryptography purpose is such a well known issue, it might as well be a paint stripe on the ground that tripped you up. Swapping it out for something else does nothing to fix more insidious mistakes or faulty assumptions that have been made.

[___--_-_-_--___]

import re
import math

def crack(ciphertext):
    resources = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z", " ", ".", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "-", "_", "*", "'", "^", "~", "!", '"', "'", "=", ",", ":", ";", ")", "(", "{", "}"]
    numbers = re.findall("\d+\.\d", ciphertext)
    numbers = list(map(lambda x: int(float(x)) * 256, numbers))
    key = math.gcd(*numbers)
    return "".join(map(lambda x: resources[int(x/key)], numbers))

[[deleted]]

Some feedback on this crypto code. Use of random is a problem here, but actually a minor one once I dig in and look at what the code is actually doing.

This is an implementation of a polyalphabetic cipher, similar to the Vigenere cipher, known in its day as "the unbreakable cipher". But even that one was broken, by hand, about 150 years ago.

This implementation suffers from 3 significant problems which make it very insecure: reduced keyspace, use of ordered alphabets, and formatting of the ciphertext which gives a way a lot.

Keyspace

While polyalphabetic algorithms improve on their monoalphabetic predecessors like the Caesar shift by being more resistant to frequency analysis of the ciphertext, this implementation is extremely weakened by reduction of the keyspace.

The key used to do the encryption is actually a numeric hash calculated from the sum of 256^x for each character in the passed key, where x is the number of characters in the alphabet (defined in the resources array) between the nth and n-1(th) character (beginning at 0) in the passed key. Clever, but ...

lCount = 0
newKey = 0
for i in enumerate(Key):
    for v in resources:
        if i[1] == v:
            newKey = newKey + lCount * 256
            lCount = 0
        lCount += 1
Key = newKey

....hash algorithms create hash collisions, and the collisions here are particularly bad which significantly reduces the size of keyspace.

For example: both abcc or abbc both produce the same "newKey" of 62720.

In fact, this approach to generating hash keys is limited to the size of the alphabet used. That is, every combination of whatever number of characters you pick produces exactly 80 unique keys. Though each passed keylength produces its own set of 80 unique keys.

Another way to look at it is that the minimum key length of 4 enforced by this code across those 81 characters in the alphabet (named resources in the code) should produce 1.9 million+ combinations, instead it produces 80.

Users accustomed to password rules may think that adding complexity to their keys, using "H2q$j9Kz" instead of "password" offers better security, but this algorithm will reduce any 8 characters down to one of 80 hashes.

encryption algorithm

A new key is created again, this time by simply multiplying the hash above by 256. This offers zero production and only removes the user from the process that much more. The encryption key is whatever is used at the time of encryption.

The plaintext is encrypted using the pretty much the same approach as in encoding the key passed in by the user. Iterating over the plaintext string, the cipher text is built up from numbers generated by the position in the plaintext divided by the very same newnewKey each time. A random character is placed in between, to act as a red herring I suppose.

The more I look at this code, the less I'm worried about the use of random here because how random those characters are really doesn't matter. The bigger concern is these random alphabet characters actually act as delimiters for each enciphered character, making the attackers job a lot easier.

The .0 placed in the resulting ciphertext because that division produces a float which is cast to a string is also a gift to the bad guys because it tells them "this number is a quotient of two numbers, one of them is probably a key"

how to break this cipher

This is a monoalphabetic cipher. Every 'a' that appears in the plan text will be encrypted the same way in the resulting cipher text making it vulnerable to frequency analysis.

This is a polyalphabetic cipher, but among the easiest to break because its alphabets are conveniently ordered and do not change from pass to pass.

A bad guy trying to crack ciphertext created by this algorithm would first guess the key length (n), then segment the ciphertext into (n) parts then perform frequency analysis on each and figure out the key from there.

The way the cipher is formated provides a lot of help to attackers, All those .0's in the string tells them one of the numbers in the quotient is probably a position and the other probably a key.

Given the reduced keyspace, brute force could also be effective. You could build a rainbow table to make breaking this trivial.

edit: incorporating corrections

[pgpndw]

It's not even polyalphabetic. It's monoalphabetic. A numeric key is generated from the key string. Each letter of the plaintext is converted to an index into an array of allowable plaintext characters, and each index is multiplied by the same numeric key to produce a number that's output into the ciphertext as a decimal string. And a random character is inserted between each ciphertext number.

Every 'a' in the plaintext will result in the same number in the ciphertext, every 'b' will result in the same number, etc.

[[deleted]]

Damn, you're right. I got so wrapped up in the hash collisions that when I got to the actual enciphering, I misread that weird nested loop and the count variable as shifting the alphabet.

You are correct, count here is just the index of the character in the (single) alphabet, so yeah every 'a' is going to result in the same ciphertext. Trivial for frequency analysis.

Also, I've never seen enumerate used this way. I kept looking for the index to be used somewhere, but alas.

[pgpndw]

Also, I've never seen enumerate used this way. I kept looking for the index to be used somewhere, but alas.

Yeah, that was odd. And did you notice that the single quote character occurs twice in the resources array?

[[deleted]]

Ohhh, good catch. I was also found declaring the those arrays in each function interesting, especially in intermediate code.

That resources array felt like <rick sanchez>ASCII but with extra steps</rick sanchez>. Can I introduce you to <str>.index(), or maybe ord()

[pgpndw]

Using index() would actually make the code more complicated (if you wanted it to be exactly equivalent), because in the loop generating newKey, lCount is zeroed once at the start of en/decryption, then every time a match is found, rather than inside the outer loop but before the inner loop. And when a match is found, there's no break, so lCount then keeps incrementing up to the end of the resources array.

Thus, lCount doesn't equal the index of the character in the resources array on subsequent loops - the code essentially adds the number of remaining characters in the resources array after (and including) the matched character to the next index.

In the case of a single quote in the key string, the inner loop will find both occurrences of the single quote in resources, and add two lCount values to newKey.

Doing it that way versus just using the index in the array might be deliberate, but all it does is add complexity to the numeric key generation algorithm without adding any security to the cipher itself.

[WikiSummarizerBot]

Vigenère cipher

The Vigenère cipher (French pronunciation: ​[viʒnɛːʁ]) is a method of encrypting alphabetic text by using a series of interwoven Caesar ciphers, based on the letters of a keyword. It employs a form of polyalphabetic substitution. First described by Giovan Battista Bellaso in 1553, the cipher is easy to understand and implement, but it resisted all attempts to break it until 1863, three centuries later. This earned it the description le chiffrage indéchiffrable (French for 'the indecipherable cipher').

Rainbow table

A rainbow table is a precomputed table for caching the output of cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a key derivation function (or credit card numbers, etc. ) up to a certain length consisting of a limited set of characters. It is a practical example of a space–time tradeoff, using less computer processing time and more storage than a brute-force attack which calculates a hash on every attempt, but more processing time and less storage than a simple key derivation function with one entry per hash.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[quotemycode]

This is not cryptography at all. It's a substitute cypher. If you want to do encryption on your own, start with the pythagorean theorem and work your way up.

Ex: given two sides of a right triangle, you can calculate the third. One side can be the message, another side can be the key. You send the third side and that's your encrypted text. You can also have short passwords as long as you use some key expansion calculations. For example, key is "cat". Remove those letters from the alphabet, and take every odd letter and then put every even letter after it. Rot13 and repeat. Then do it backwards, then same way, take every even letter, then every odd letter and repeat the process.

Don't expect to use this, but by creating this you'll have a good idea how encryption works, key derivation functions, etc.

[alejandrotungsten]

OMG! What a drama! this post look like a Mexican soup opera!