I made this encrypt some text, but it is impossible to unencrypt you should look and see why.
Encrypt by wawa2016 | Snap! Build Your Own Blocks
I also have a python file on GitHub (If you can get there) GitHub - wawa2016-here/Encrypt · GitHub and C file
Hey uhhh… I think these shouldn’t be equal!
(forgive me for the Scratch/Split! blocks, I forgot to disable that :( )
This type of encryption is called hashing, and algorithms like this one are used to protect passwords.
This is a hash collision. If this algorithm was used to protect actual passwords, you’d need to keep collisions in mind. This specific collision means that if your password was A, an attacker could guess that your password is B and log in to your account!
It’s not, but it’s extremely close to one. This effect is caused by rounding ASCII/Unicode values, so values close to each other in the table are treated the same.
Maybe that’s the point, since there are so many collisions, you can’t guess what the original was 
Well let me fix that.
And I forgot about input slots.
Fixed it and added input slots.
And the reason why you can unencrypt it is because I used the round block. (This used decimals.) So now you see why.
The problem with round’s collisions is that they’re right next to each other
Most hash algorithms get around this by exploiting the pigeonhole principle. In other words, they make their hash algorithms have a finite number of total outputs. This makes collisions a lot more spread apart.
How can you implement this in Snap?
The output of the (x mod y) block is always between 0 and y, so just slapping it on the output in random places is sufficient for a toy algorithm.
With the addition of this block, the algorithm already becomes irreversible in theory, so there would be no need for rounding, solving this algorithm’s current biggest problem.
This is an example of a professional hash algorithm that’s being used to defend you from hackers right now. Notice how the output remains small, no matter how large the input is.
You people have fooled me = is wrong they are different there is a limit to the = operator they actually are different. I was told this thing does not have infinite precision so JavaScript rounds it before preforming the check leading to this false result. And the input who cares how long it is as long as it works, I’m fine. Maybe if you have a large file, it could matter but right now I don’t think it does.
Next time lets run each of them separately and compare ourselves.
What?
I’m not lying.
I didn’t say that. But, I couldn’t tell what you said.
Let’s just say when you use more that 15 digits in JavaScript it gets inaccurate.
Obviously
This one shortens the output a lot so if you have a long paragraph and you do this it will be shorter and have less size.