Decrypting Encrypted Messages | Easy Algorithm and Challenge

  • Thread starter Thread starter Hillrunner
  • Start date Start date
Click For Summary
The discussion revolves around decrypting an encrypted message using a specific algorithm. The plaintext is divided into 16-character blocks, which are converted into BigIntegers by interpreting them as base 128 numbers, with ASCII codes represented in 7 bits. Incomplete blocks are padded with blanks, which are clarified as zeros to complete the BigInteger representation.Participants explore the conversion process, noting that each character's ASCII value is taken, the first bit is removed, and the resulting 7-bit values are concatenated to form a large number. An example illustrates how the string "hello" converts to the number 28130883183 before encryption. The encryption involves multiplying this number by a secret key, leading to a series of encrypted BigIntegers. Questions arise about the nature of the key, whether it is a single integer or a range of values, and the handling of the padded blanks in the final representation. The discussion emphasizes understanding the conversion and encryption process to facilitate decryption without the key.
Hillrunner
Messages
2
Reaction score
0
Hey folks,

I have a bit of a brain teaser I'm stumped on at the moment. I have an encrypted message I could use some help decrypting. The encryption algorithm is as follows: Read the plain text into 16 character blocks. Each such block will be converted to a BigInteger by treating it as a 16 digit number in a base 128 number system. (The ASCII code of a character is 7 bits.) Incomplete blocks should be padded up by blanks at the end. This will produce a sequence of
BigIntegers representing the block-by-block encoding of the plain text input. Then those BigIntegers will be encrypted by multiplying each by a BigInteger (the Key) that is supposed to be secret.

This is very straight forward and easy to implement, but decrypting a secret message without the key is my current goal. If you are up for the challenge give this a shot and keep me posted on the results.

3722413721597234206507650923983285120166901260478730869
6736638976638615758622997116823310767096086080786804802
1836714918194979944137126492369500940937915708565964527
6200450286565486196074388059858603808398976724101400303
5750288060945256026702605821838960267473373177639409286
5832816355098275829201875849607446439291341167953035910
5663374800875719056491076033940220393576824222551138258
6371670599832070641542158304833756560944630944109070063
6200450286568057203187204796088787244633533579439898834


Again, this would be divided by the secret key, and then the plain text could be derived by modding and dividing by 128 and converting into ascii.
 
Physics news on Phys.org
Hmmm... I don't quite get it--

Hillrunner said:
Read the plain text into 16 character blocks.

So the first "16 character block" is "3722413721597234"?

Hillrunner said:
Each such block will be converted to a BigInteger by treating it as a 16 digit number in a base 128 number system. (The ASCII code of a character is 7 bits.)

Treat the 16 digit number above as a base 128 number? If so:

4 => 4
34 => 388
234 => 33156
7234 => 14713220
97234 => 283148676
...

The number in question would require (I think) 14 bytes to represent it, but a Big Integer is typically only 8 bytes?

Hillrunner said:
Incomplete blocks should be padded up by blanks at the end.

What is a "blank"? You mean that the remaining bits should be 0-filled to complete a "Big Integer"? Assuming that this is supposed to be a 16-byte integer, would that mean filling the remaining 16 bits with 0's?

Hillrunner said:
This will produce a sequence of BigIntegers representing the block-by-block encoding of the plain text input.

ASCII encoding? I missed something, because if the last 2 bytes are always 0-filled, that's not an ASCII character.

I think I missed something in there somewhere. :confused:

DaveE
 
I'll clarify with an example. hello would be converted to 28130883183 before encryption.

So, to decrypt this decoded integer string I would simply do 28130883183 mod 128 = 111 (111 = the ascii character o). o is the last character in the character string hello. To get the remaining characters, I would dive 28130883183 by 128 and mod again by 128.

Ex. 28130883183 /128 = 219772525

219772525 % 128 = 109 ( the letter l in ascii)


Hope that helps you understand. Sorry I wan't more clear the first post.
 
Hillrunner said:
I'll clarify with an example. hello would be converted to 28130883183 before encryption.

Ok, so to convert from the string to the number, you're taking the ASCII value of each character, removing the 1st bit (which is necessarily 0 in normal ASCII), and then concatenating each of the 7-bits together to form a resultingly huge number, which is then interpreted into a resulting number.

Example:
h => 104 => 1101000
e => 101 => 1100101
l => 108 => 1101100
l => 108 => 1101100
o => 111 => 1101111

Results in: 11010001100101110110011011001101111
Which translates to: 28130883183

So, OK, I get that part. Now, there's something else about an encryption key-- I assume you mean to suggest that this number (28130883183) is multiplied by the encryption key, producing a different number, which is the one (or ones?) you posted earlier? Does that mean that each one of the 9 numbers you posted is a separate number? Or is it all one big number? Is the scope of the key known? That is, is it an integer? A fraction? An irrational number? Is it within a certain range?

Finally, where do the "blanks" come in?

DaveE
 

Similar threads

Replies
17
Views
616
  • · Replies 13 ·
Replies
13
Views
4K
  • · Replies 52 ·
2
Replies
52
Views
6K
  • · Replies 9 ·
Replies
9
Views
3K
  • · Replies 3 ·
Replies
3
Views
8K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 1 ·
Replies
1
Views
6K
  • · Replies 13 ·
Replies
13
Views
4K
Replies
1
Views
3K