AutoHotkey Community

[MIchael]

Hello
I have been reading the posts about en /decryption with external progams but Im wondering if I can get it to work the way I need it:
I would like the make an encrypted ini file. So far no problem
but the ahk script should read the contents of this ini file on the fly into several ahk variables that means without decrypting it to a new file or without using the clipboard.
Can you give me a hint how to do it?
Thank you very much for your help!!!
ciao
Michael

[Titan]

Use FileRead on the encrypted ini (make sure it doesn't have any binary zeros)and run it through the decryptor program with /decrypt switch or whatever appropriate. If the decryptor makes a file containing the decrypted text use FileRead again and you'll have the decrypted contents in a variable.

[Rubberduck]

I think that is exactly what MIchael don't want.

If he is decrypting it to a file he is having this file on disc (what he not wants).

I think of two solutions:
1: The external decrypt-programm allows DLL-Calls then everything
can be done within memory.
2: Following Titans advice:
- decrypt to disk,
- read decrypted file with AHK
- erase (full secure erase) decrypted file from disk using a second external wiper-program.
_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

[Laszlo]

Your AHK script could contain a large table of random characters, a One Time Pad (OTP).

When you create an encrypted INI file, you choose an offset, and write it in the beginning of the encrypted file. The INI file is then read in and XOR-ed byte-by-byte with the OTP bytes starting with the right offset. The result is the rest of the encrypted INI file.

When you read the encrypted INI file, you first read the offset from the beginning of the file, and then XOR the right OTP bytes to the bytes read from the encrypted INI file. This gives you back the original text.

Assuming the INI file contains only ASCII characters less than 128, the OTP can have also the MS bits 0. If you do a smarter mapping instead of a simple XOR, there will be no need for binary files. Characters with ASCII code between 32 and 127 should be mapped to the same range, line feed and carriage returns could be left alone (assuming this does not leak important information).

[Rubberduck]

Ah Laszlo, you Maths-Profi ,
you have been faster than me.

I am just reading in the book "Entzifferte Geheimnisse" by
Friedrich L. Bauer to find a good encrypt/decrypt-solution to
implement it for MIchael. This book about
encryption-history (but too much Maths for me ) is really good.

Maybe MIchael should read it, but the OTP-idea is good enough for
simple security.

P.S. @Laszlo. Also die Ameisen-Sache in AHK lasse ich dann lieber
_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

[Laszlo]

By a smarter mapping I meant something like the following

[Chris]

[Laszlo]

Chris, if you change it, some existing scripts will break. How about providing the other sign rules in another function, like Rem() - meaning remainder? It is also useful for floats, e.g. when you need to reduce a (positive or negative) angle to [0, 2 pi]. I’d prefer the names of the function swapped, so that Mod() returns non-negative results with positive divisor, but others might disagree.

[Chris]

If Mod() is fairly incorrect the way it is now, it should probably be fixed. As long as the change is announced, breaking existing scripts seems justified given how recently Mod() was added.

Assuming Mod() is changed, I suspect no additional Rem() function would be needed by the vast majority of users.

Thanks.

[MIchael]

Hello Laszlo and you all!
thank you for your thoughts. I think I understood the meaning of your OTP. But I think Im not skilled enough to implement it, espacially what you posted in your second post ....
I Think I have to stick to Rubberducks/Titans advice and create a file, read it and secure erase it from disk.
Or is there any way to write the contents of the encrypted file directly into a ahk variable instead of a file?
(I would like to use axcrypt for de/encryption and this programm has only support for a file...)
ciao
MIchael

[Laszlo]

Well, it depends on your security requirements. AHK can be stopped (paused, suspended) before the secure erase command could be issued, and so the decrypted file became visible. If it is a problem, you should disable the Windows Task Manager, remove the Tray menu for your script and hope that your adversary does not write a simple script, which checks if the decrypted file appears on disk and copies it for himself.

Somebody with a little free time could help you with the OTP idea. I don’t think a complete solution (en + decryption) takes more than 20 lines of code, and you can work with text files only.

[Chris]

Not to distract from the topic above, but returning briefly to the mod() issue: I'm not a heavy user of mod() so don't have a strong preference. If anyone uses it a lot or feels the behavior of negative numbers should be changed (as described a few posts up), please let me know. Otherwise, I'll leave it the way it is.

[Laszlo]

Even if Mod() remains unchanged, it is not a big deal. The version with nonnegative results (for positive modulus) is easily derived: