Try it out at
Decryption is just division. Text is treated as Unicode.
I believe it is very strong encryption but I'm no expert.
Project idea inspired by Snap!Con Encryption BOF
Hey,are you chinese?
I used Google Translate to test whether this works with any character set.
It works fine in Chrome and FireFox. I wonder if Snap!'s say is the problem.
Try copying and pasting the Chinese text and emoji into a say block and see if you have the same problem.
I figured out what the problem is. If you don't click the green flag the secret key is what was saved and bignums are saved as zero. See https://github.com/jmoenig/Snap/issues/2668
Zero is the only bad integer secret key.
I fixed it by saving it with a small integer key. And producing a warning for keys equal to zero.
And thanks for reporting the problem.
很高兴见到你，电信用户？汉字U码范围一般常用字：4E00（19968） --9FA5 （40869）。我带的兴趣小组也在尝试做字符加解密（颜色或者声音嵌入字符），看到那个色块例子了，正设法转到中文。
The U code range of Chinese characters is commonly used: 4e00 (19968) - 9fa5 (40869). My interest group is also trying to do character encryption and decryption (color or sound embedded characters). Seeing the color block example, I am trying to switch to Chinese.
Elegant and powerful encoding and decoding scheme. Thanks for sharing.
Well,are you using google translate?
edge translate and copytranslator.
感谢，不过大数分解，学生不懂。这种简单映射无太多理论基础。像公钥私钥那种只是简单提及一下。
Thank you, but the decomposition of large numbers is beyond the student's comprehension. there is not much theoretical basis for such simple mappings, like public and private keys, which are only briefly mentioned.
You don't need to translate it since I can read english.
Like public key schemes this relies upon the product of big integers. Unlike public key schemes this is a cypher that just has one key. There is no need to think about prime decomposition here. It only relies upon this fact:
x = (x * y) / y
I would be surprised if this is beyond a student's comprehension.
It does, however, depend upon understanding how numbers can be presented in different bases. But if a student understands binary or hexadecimal what is sort hard about other bases?
I've updated the project to use 2^16 as the default base. But it still works with 2^32 except that the encryption is in base 10 while with 2^16 one can obtain base 10 or base 2^16. This is because while Unicode can go beyond 2^16 characters they aren't well supported.
Of course, You know that this script displays the secret key?
It's a basic kind of cryptanalysis known as Chosen/Known-Plain-Text Attack.
Nominally, in the best-case scenario, Your key has 128-bit length. In worst-case, the generated key may have only neglectable entropy. So, even to get a decent key, special measures must be taken. At least the key can be hashed.
There are also other techniques e.g.
- padding (filling plain text with extra garbage to nominal length)
- adding "salt" included with the encoded text.
This way the same text and secret key give different results every time.
But your script already has access to secret key.
I just quickly generated a key and you are right that it is too small. But there is no limit to the size of the key. And it is easy to generate very long keys either by multiplying lots of random numbers or using a long pass phrase:
Thank you. I've learned a lot in the forum .
This cipher can be attacked by simply seeing several messages encrypted by the same key. Consider a list of ciphertexts:
The GCD of the plaintexts happens to be 1. The key can be extracted by taking the GCD of the ciphertexts:
The GCD of two numbers can be found quickly using the Euclidean Algorithm, without having to factor them.
Very nice.
How about if each message is multiplied by (secret key + sequence number) where sequence number is incremented after each encoding and can be sent along with the encrypted message? It seems that would stop a GCD attack.
Also where are a and b defined? Should they be x and y?