string encryption

[Hiemlick Hiemlicker via Digitalmars-d]

On Friday, 1 July 2016 at 22:56:48 UTC, Basile B. wrote:
> On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker 
> wrote:
>> I know this is probably a lot to ask for an many won't see the 
>> point, but a secure program should not expose readable 
>> strings, it makes it far too easy for the attacker to see what 
>> is going on.
>>
>> Is it possible to encrypt every static string in D and decrypt 
>> before it is output in an automatic fashion?
>>
>> Even something like
>>
>> e{This is an encrypted string}
>>
>> which encrypts the string using a user defined function(which 
>> is ctfe'able) is better than nothing.
>>
>> Even a simple xor type of cypher is better than nothing. 
>> Obviously optional.
>>
>> The problem is that there is no way to encrypt strings in the 
>> binary through code because one must pass express the string 
>> non-encrypted to the encryption function.
>>
>> encrypt("This string will still end up in the binary");
>>
>> even though the string is only used once, at the encryption 
>> call site. It seems D won't replace
>>
>> encrypt("This string will still end up in the binary");
>>
>> with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or 
>> whatever the ctfe value of encrypt actually is.
>>
>> This also seems like a bug in D because manifest constants 
>> used as sole arguments to ctfe'able functions should be 
>> replaced by the function result.
>>
>>
>> e.g.,
>>
>> factorial(3) should be replaced by 6 and the function should 
>> never be called at run time. This is the whole point of ctfe, 
>> is it not?
>>
>> I'm not actually sure if the functions are ctfe'ed and the 
>> un-encrypted string is just stored in the binary or what but 
>> it's there
>>
>>
>> import std.stdio;
>>
>> string e(string s)
>> {
>>     string q;
>>     foreach(c; s)
>>         q ~= c + 1;
>>     return q;
>> }
>>
>> void main()
>> {
>>    writeln(e("What is this string doing in the binary?"));
>> }
>
> You must make a template that follows this pattern:
>
>     template KrypticString(string s)
>     {
>         string processor()
>         {
>             return /*do some stuff here on 's'*/ "";
>         }
>         enum KrypticString = processor();
>     }
>
> It's already used in phobos for example for octal() and 
> hexString(). Also seen i dont remember where, for a float 
> format.
>

ok. For some reason I thought CTFE's applied to normal functions 
but I realize that doesn't make a lot of sense. (would be nice 
but most functions are not CTFE'able and the compiler would have 
trouble figuring that out)

> But another important thing is that you must absolutely not 
> release with -debug.
> Strings are a thing but every one who has made the thug with 
> IDA knows that the most usefull informations are the "Names" 
> and not the "strings". The calls to the OS API can't be easily 
> hidden, they are always in the "Names" but D functions names 
> can.

Yes, of course. Do D names change depending on -debug vs -release?

> For example it's even not worth crypting the strings if the 
> attacker can see
>
>     _D4main7decryptFAyaZAya
>
> in the "Names", because in this case he "just" has to put a 
> breakpoint on the C3 of the matching function, look for the 
> decrypted string in memory, and bookmark the static addresses 
> of the parameters passed to this function during the execution.
>
> Also, if you take a minute to think a bit you'll find that 
> cryptic strings will hit the eyes of the attacker quite 
> quickly: "mmmh why is the content crypted ?!, let's see 
> that...".


I'm not too concerned about the attacker seeing them because they 
will have to watch every decryption to get the string(or possibly 
write a utility to automate the decryption).

If everything is encrypted it will give the attacker grief far 
more than being decrypted.

If pretty much every string is encrypted then it will make his 
life a little more difficult I would think. After all, it is 
impossible to completely stop an attacker given enough time and 
energy. The goal is to make it not worth it.

Also, Is there a simple way to make this work for "direct" output:


writeln(de_encrypt!("This is my string"));

it encrypts it at compile time but decrypts it at run time.(hence 
no binary)

Alternatively, treat every string as a call to an anonymous 
function that decrypts it at runtime(possibly using different 
cypher).

e.g.,

enstring s = "This is really an encrypted string function";


enstring could wrap opCall which decrypts it when used. This 
might be a drop in replacement for string?

s() calls the decryption function, which is uniquely generated 
for each string. We can drop the ()...

This would definitely add an order of magnitude to the complexity 
of decoding the strings.