2019-03-20 16:50:00

I was board so I encrypted a text file in BGT.
The key was 16 chars long, so that way I figured it might be accepted better.
This file just contained text, but decrypting it with Pycryptodome never worked sad
Am I missing something?
If like me you're board enough, please help LOL.

2019-03-20 16:56:54

If you can find which algorithm BGT uses for encryption you sure can decrypt. You also have to find if the text has been encrypted with multiple algorithms, if it has been hashed before the encryption etc etc.

Paul

2019-03-20 16:59:21

Will require reverse-engineering of bgt's encryption algorithm. Not super hard to do, but why would you want to?

Roel
golfing in the kitchen

2019-03-20 19:51:50

I'm interested in things like this.
Also, the documentation for file_decrypt says BGT uses Rijndael 256 bit to decrypt and encrypt the data.
I guess the reason you can use a key of any length is because the program can hash it.

2019-03-21 00:28:43 (edited by Rastislav Kish 2019-03-21 00:30:22)

Yes and no. Why? You can find out the answer very easily yourself.
In bgt, create one string called playnText. Save this string to file and encrypt it using file_encrypt function.
Then load the encrypted file to string called enc1.
After it, encrypt playnText string using the same password with string_encrypt function and save the result to enc2 string.
Now, because of the same encryption algorithm used with the same password, you might think that enc1 and enc2 will be equal.
The reality is also answer to your question regarding decrypting using python.

Best regards

Rastislav

2019-03-21 05:04:53 (edited by Ethin 2019-03-21 05:05:58)

@5, I don't really get what your getting at, and either way that doesn't really answer the question.
BGT uses Rijndael 256 (which is AES-256). It does not, however, state which cipher mode it uses. You would need to try each and every mode, figure out how the nonce is stored, ensure you had the key and then work on decryption.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-03-22 17:02:20

How do you think BGT allows you to use a key of any length?
Does it hash it, creating a string that's always the right length, or does it just add a sequence of characters to the end til it's long enough?

2019-03-22 22:53:31

@7, Rijndael allows key lengths (up to some library-determined limit, which is implementation-specific); AES only allows you to use 128, 192, or 256-bit keys (that's 16, 24 or 32-bytes). You might ask how that's secure; the simple answer is that since you can use any character (even NULLs) in your keys for most libraries, you can use any character in the universe. If your implementation allows, you can even use invalid UTF-8 code points! If we consider only the valid code points (1112064) you have, roughly, 10^(10^6.126799545566277), 10^(10^6.186075342271296), and 10^(10^6.223709558574334) possibilities for your key. Let's just say that all three of those power-of-10 representations are incredibly large numbers and leave it at that. If you include the invalid code points too, you have limitless possibilities that are impossible to test. (Unfortunately, I don't know of any UTF-8 library that will allow invalid code points; every one I know will replace them with some other code point that's valid, if the OS doesn't do it first.)

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github