How does Python tell that an integer is actually an integer?

[PeterDonis]

I meant this

Then you are using the wrong operation. You don't want to convert an integer to a string. You want to convert a string (the message) into an integer (or a sequence of integers).

In my previous post, I was trying to say that you'll need a lot of storage if you store the key as binary. But an ASCII key will be more useful in terms of storage.

You are very confused.

First, as I have already pointed out, "binary" is not a Python data type. What you are calling "binary" are Python strings that contain "0" and "1" characters that can be interpreted as the bits in a binary representation of an integer, but that does not mean you should actually use this for any kind of arithmetical or logical operation. That's not what the bin() function is for.

You say this bin() conversion is an intermediate step, but I don't think you've fully thought through what you are doing. If you already have an integer representing a character in the message and an integer representing a character in the key, you can just xor them directly in Python. There is no need to convert them into these "binary" strings.

If your message is "password," and if you want to make the XOR encryption "unbreakable," you need to create a random binary key that is 64 bits long.

Yes, and this is a 64-bit integer. It's not a string of 64 bytes that are either "0" or "1".

For instace, I have generated a random binary key. So for an unbreakable message you'll need to store this.

0000110011010000111111100100101110110010010011110110110000101011

but if you convert this into ASCII (or as ASCII key), you'll need to store just

♀ÐþK²Ol+

First, most of those characters aren't ASCII characters, so the term "ASCII" is incorrect.

Second, since what you have is a 64-bit integer, you should just represent it as a Python integer and do Python operations on it directly as an integer.

Here, the only problem is that the binary representation of the key can also represent the unprintable ASCII characters.

The "unprintable" characters aren't ASCII characters to begin with, as noted above. But more important, viewing them as "characters" makes no sense. As above, you have a 64-bit integer. You can represent integers directly in Python as integers.

Instead of turning 67 and 45 into bytes and then doing XOR bitwise I could have just do

bin(67 ^ 45)

which gives the correct answer. This approach will definately shorten my code

Exactly! Except that there is no need for the bin() function anywhere. You have an integer; if you want to convert it to a character, you call ord() on it, not bin().

You guys are giving hints but I cannot understand something that i don't know...

What are you talking about? You just did understand it (in what I quoted above and responded to with "Exactly!").

Hex is a good approach

What? Why are you throwing away the right answer right after you found it?

 

[Mark44]

What you are calling "binary" are Python strings that contain "0" and "1" characters that can be interpreted as the bits in a binary representation of an integer

Again, the OP seems to be confused about the difference between a numeric digit character, like '0' and a numeral, like 0.

The character '0' has an ASCII code of 48 (or 0x30 in hex or b110000 in binary). The number 0 has all its bits cleared to 0.

 

[Arman777]

Then you are using the wrong operation. You don't want to convert an integer to a string. You want to convert a string (the message) into an integer (or a sequence of integers).

Yes you are right I have realized that later on.

You say this bin() conversion is an intermediate step, but I don't think you've fully thought through what you are doing. If you already have an integer representing a character in the message and an integer representing a character in the key, you can just xor them directly in Python. There is no need to convert them into these "binary" strings.

Yes you are right. The problem was I was not aware of that kind of operation was avaliable in python. So that was why I was trying to strange stuff.

Exactly! Except that there is no need for the bin() function anywhere. You have an integer; if you want to convert it to a character, you call ord() on it, not bin().

Yes I have also realized that

What are you talking about? You just did understand it (in what I quoted above and responded to with "Exactly!").

Well It was a late enlightenment for me. In my head I was keep repeating what these guys want.

What? Why are you throwing away the right answer right after you found it?

I was just thinking that can be a good idea. But I can also change the encrypted message to to a list of integers (or hex) which seems more reasonable. Such as

encrypted_message = encryptXOR('I have a dream', '999')
decrypted_message = decryptXOR(encrypted_message, '999')

print(encrypted_message)
print(decrypted_message)

will output

[112, 25, 81, 88, 79, 92, 25, 88, 25, 93, 75, 92, 88, 84]
I have a dream

 

[pbuk]

Arman777 said:
Hex is a good approach

What? Why are you throwing away the right answer right after you found it?

I think @arman here means that he realizes hex can be useful for external representation of arbitrary 8 bit values; hex is much more compact and easier to read than strings of 0's and 1's and does not suffer the problem of unprintable characters of direct extended ASCII rendering.

The light regarding internal representation does seem to have clicked on

 

[Arman777]

I think @arman here means that he realizes hex can be useful for external representation of arbitrary 8 bit values; hex is much more compact and easier to read than strings of 0's and 1's and does not suffer the problem of unprintable characters of direct extended ASCII rendering.

The light regarding internal representation does seem to have clicked on

Yes exactly. I was talking about external representation

 

[AdvaitDhingra]

I think Python determines types at runtime unlike other languages like C++.

 

[hmmm27]

Yes exactly. I was talking about external representation

That goes a long way towards explaining why I spent the last couple of pages thinking that at least one of us is an idiot. Sure, you can do the whole thing in display-types ; it's a CLI ; machine efficiency isn't an issue.

What course/textbook ? what's the title of the chapter ? What's the exact wording of the problem ?
(ie: "summary"),

What coding, language, application constructs do you think would be useful ?
(ie: "equations")

What have you accomplished, and how are you stuck ?

 

[Arman777]

one of us is an idiot

No one has to be an idiot. Its important to learn from our mistakes and we may not be know everything.

What have you accomplished, and how are you stuck ?

I have finished the coding actually. I even created a GUI

You can check here

https://github.com/seVenVo1d/random/tree/master/XOR%20Encryption

I could have shared the code here but the site is giving errors.

 

[mamba76]

Interesting the word 'pointer' was used once in this whole thread, didn't see registers mention either. Study an introduction into assembly language then the OP should be able to easily understand..

 

[pbuk]

How do you think a knowledge of assembly language and CPU architecture will help the OP understand how Python remembers that a variable holds an integer value?

 

[lyuc]

I have finished the coding actually. I even created a GUI

https://github.com/seVenVo1d/random/tree/master/XOR%20Encryption

Your link is wrong.

I looked at the non-gui code.

This actually works with unicode, not just ascii. You can happy type accented letters such as å, chinese characters such as 龙, and emoji such as into it, and it'll still work. One of the benefits of Python 3.

As a further exercise, you might want to change the output into some kind of more compact format. A cyphertex of "A@E3" might be more useful and portable than "0x1F,0x02,0x3435".

 

[Arman777]

Your link is wrong.

Thats possible. I am changing the names and the code itself most of the times.

As a further exercise, you might want to change the output into some kind of more compact format.

I have thought about it and limit the output only printible characters or as you have pointed out I could have removed the '\x' in front of them

I looked at the non-gui code.

Thanks for checking it out.

 

[lyuc]

The lazy way to do it would be to take the raw bytes and then use base64 encoding, or uuencode.