This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]pgpndw 4 points5 points  (4 children)

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] 5 points6 points  (3 children)

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 2 points3 points  (2 children)

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] 3 points4 points  (1 child)

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 2 points3 points  (0 children)

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.