*Yes this goes a bit into `constexpr`* So I want ...

# language-proposals

[jaqxues]

Yes this goes a bit into constexpr

So I want to make my App a bit harder to reverse engineer. There are only a few critical points that are actually important, in this case `String`s. So what I would love to do, just to make it a bit harder (I do know very well that it is still absolutely possible to get the strings), I want to encrypt the `String`s into encrypted `ByteArray`s

Kotlin has everything in place to allow for an extremely nice implementation

val encryptedStringExample by encryptedString { "Some_Secret" }

The Delegate uses a constexpr to go from the String to an encrypted ByteArray and stores it as field. Hence the String itself cannot be found in the actual compiled code. The decrypted value is just the getValue operator of the delegate.

println(encryptedStringExample) // Some_Secret

However, Kotlin does not yet support constexpr and the "Some_Secret String would always be found in the (Jvm) Bytecode, even with all fancy inlining etc.

So my question / request is, is there any news on this? (https://youtrack.jetbrains.com/issue/KT-14652). Or do you have any other ways to offer to achieve this or something similar?



Of course I do understand that the key would have to be final to allow to be used for a constexpr (so it really just is to make it harder to find the string in the first place), but this could be useful for some other use cases too

[jaqxues]

"Implementation" of the Delegate

@ExperimentalStdlibApi
val r by encryptedString { "HELLO" }

@ExperimentalStdlibApi
inline fun encryptedString(crossinline s: () -> String) = EncryptedStringDelegate(s().encodeToByteArray())

class EncryptedStringDelegate(val byteArray: ByteArray) {
    @ExperimentalStdlibApi
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String = byteArray.decodeToString()
}

The string itself would be evaluated in the constexpr , the String would not be in the bytecode. That is the ultimate goal

[gildor]

Looks more like work for obfuscator on bytecode level, not for language feature

Also if it would be a language feature very soon it will be written very simple utility which "decrypt" all those string, at least obfuscator could use different strategies and change it on every compilation

[jaqxues]

I do admit this is not a "perfect" use case, but I still like that idea of constexpr
So I guess this won't be added in the future

[gildor]

There is an issue about generic constexpr feature:
https://youtrack.jetbrains.com/issue/KT-14652