Blowfish - on a string

[Lindon]

I dont want a file based solution - I'm looking for a way to encrypt and decrypt and arbitary string - is that possible?

[d.healey]

@Lindon I don't see anything in the API or in the JUCE reference for that.

[ustk]

@Lindon I've just added two methods:
https://github.com/christophhart/HISE/pull/331

to use this way:

[d.healey]

@ustk Nice :D

You can use the expansion encryption key from project preferences so you don't have to include the key directly as a string.

const encryptionKey = Engine.getProjectInfo().EncryptionKey;

[ustk]

@d-healey Cool, didn't know it was accessible from script :)

[d.healey]

@ustk It was something I added a few months ago

[Lindon]

@d-healey @ustk - thanks go to both of you then...

[Lindon]

@d-healey said in Blowfish - on a string:

@ustk Nice :D

You can use the expansion encryption key from project preferences so you don't have to include the key directly as a string.

const encryptionKey = Engine.getProjectInfo().EncryptionKey;

Does this mean the key isnt "readily" readable from the code - meaning a hacker cant see it "easily"? or am I getting confused...as is not unusual thers is zero documentation for getProjectInfo()

[d.healey]

@Lindon said in Blowfish - on a string:

Does this mean the key isnt "readily" readable from the code - meaning a hacker cant see it "easily"?

The encryption key will be read directly from project_info.xml. I'm not sure how that's included in the binary but it will still be there in plain text somewhere I assume. Encrypting things client side is like putting a really good lock on a balsa wood safe.

as is not unusual thers is zero documentation for getProjectInfo()

That's because I haven't written any :)

[Lindon]

@d-healey said in Blowfish - on a string:

@Lindon said in Blowfish - on a string:

Does this mean the key isnt "readily" readable from the code - meaning a hacker cant see it "easily"?

The encryption key will be read directly from project_info.xml. I'm not sure how that's included in the binary but it will still be there in plain text somewhere I assume. Encrypting things client side is like putting a really good lock on a balsa wood safe.

Perhaps - perhaps not....

[Lindon]

@ustk - this is great by the way - so thanks for this - but what I really really really would like is to have this implemented:

JUCE: RSAKey Class Reference

(docs.juce.com)

..as the first part of these recommendations from Urs:

Just a moment...

(www.kvraudio.com)

Just a moment...

(www.kvraudio.com)

[ustk]

@Lindon I do not have the time right now but I'll check this evening.
But what I can say already is that the RSA encryption is made of a public and a private key, meaning the encryption has to be made externally (online), otherwise it makes no sense to have both encryption and decryption from within the same app.

This is why Christoph implemented it for the unlocker system

[Lindon]

@ustk yes I understand the encryption and decryption have to be done in different applications (neither needs to be an on-line service) .

In fact if you read thru Urs comments closely you will see that he recommends AGAINST on-line based solutions as one of the things that is a single point of failure that hackers look for straight away and can work around easily...

[Lindon]

@ustk said in Blowfish - on a string:

@Lindon I do not have the time right now but I'll check this evening.
But what I can say already is that the RSA encryption is made of a public and a private key, meaning the encryption has to be made externally (online), otherwise it makes no sense to have both encryption and decryption from within the same app.

This is why Christoph implemented it for the unlocker system

Hey @ustk - did you get any chance to look at this?

[Christoph Hart]

I'm not sure how that's included in the binary but it will still be there in plain text somewhere I assume

The RSA Key is mangled before it's embedded into the binary. This makes it a little bit harder to crack, but I wouldn't count on it saving your protection.

But there is absolutely no point in adding a RSA protection on the scripting layer because the weak point is the plainly readable script code, not the encryption algorithm.

[Lindon]

@Christoph-Hart said in Blowfish - on a string:

I'm not sure how that's included in the binary but it will still be there in plain text somewhere I assume

The RSA Key is mangled before it's embedded into the binary. This makes it a little bit harder to crack, but I wouldn't count on it saving your protection.

But there is absolutely no point in adding a RSA protection on the scripting layer because the weak point is the plainly readable script code, not the encryption algorithm.

sigh - once more with feeling.....

Please please please please please go read the entirety of what Urs has to say on this subject, I've posted the links above.

But your are correct having RSA keys does not offer a complete solution, because as you point out the scripting is visible, as it is in any solution - including "calling home" ones oft recommended and promoted here.

What having RSA does (and the only thing it does for you) is stop keygens. You encode a set of serial numbers outside of the plugin using the private key, you give one encoded serial to each valid customer. The plugin uses the public key to decrypt this serial - and check against the array of serials (that is clearly viewable by the pirate) inside the plugin.

The pirate cannot generate new serials because they dont have the private key, so they must alter the code itself, and then ship this "cracked" version.

This is all I'm trying to do in this first step of the ongoing battle. It is the SIMPLEST way to make the pirate hack the script. Simpler by far than some call home server based solution, which if you read Urs commentary you will see is the first thing the pirate looks for and circumvents.

Every single solution that uses scripts in ANY way is as vulnerable as any other - but RSA encryption of serials is (as far as I can see) the cheapest and easiest way to force the pirate to the next stage of hacking...

..and as an aside gives me a way to validate server messages at some point in the future...

[Christoph Hart]

If you think this is your line of defense

The pirate cannot generate new serials because they dont have the private key,

then this is the attack vector:

and check against the array of serials (that is clearly viewable by the pirate) inside the plugin.

A keygen would simply contain the "clearly viewable" list of valid serials and spit out one of them:

inline function nastyKeygen()
{
     return extractedKeys[Math.randInt(0, extractedKeys.length)];
}

If you want to up your copy protection game, just use the ScriptLocker class. This enforces a system identification and a server call, but if your server is hacked, then you might as well give up.

[Lindon]

@Christoph-Hart said in Blowfish - on a string:

If you think this is your line of defense

The pirate cannot generate new serials because they dont have the private key,

then this is the attack vector:

and check against the array of serials (that is clearly viewable by the pirate) inside the plugin.

A keygen would simply contain the "clearly viewable" list of valid serials and spit out one of them:

inline function nastyKeygen()
{
     return extractedKeygens[Math.randInt(0, extractedKeygens.length);
}

If you want to up your copy protection game, just use the ScriptLocker class. This enforces a system identification and a server call, but if your server is hacked, then you might as well give up.

well I think one of us doesn't understand RSA = it could well be me....

Heres a serial: 1234-1234

I take the encrypting(private) key and generate an encrypted version....

qw247dnwpoie75hb4985345h34

I give this to my customer....

My app asks for this encrypted key:...

The app contains the decrypting(public) key:

333eee333eerr444rrr

it uses this public key to decrypt it the serial provided by the user, getting:

1234-1234

it checks against the array of valid serials held in the app:

1234-1234
5668-5678
2345-6784
2291-6144

its present so valid all good....

Along comes my pirate, he gets a copy of my app:

he can see the list of serials...

1234-1234
5668-5678
2345-6784
2291-6144

he can see the public key:

333eee333eerr444rrr

Okay so now he needs to generate an encrypted serial that will be decrypted by the public key....for that he needs the private key....he doesn't have it..and its very complex to get it. So he will have to hack the code.

Did I misunderstand something?

[Lindon]

@Lindon so I think what I'm looking for is these JUCE calls to be implemented in HISE

static void RSAKey::createKeyPair(
RSAKey & publicKey,
RSAKey & privateKey,
int 	numBits,
const int * 	randomSeeds = nullptr,
int 	numRandomSeeds = 0 
)	

which is a convenience but gives me two RSA keys...

and this:

bool RSAKey::applyToValue(BigInteger & value)const

which I can use with the encoding key to encode my serials, and with the decoding key to decode them...

[Christoph Hart]

@Lindon Actually, no, you're right. I forgot the decryption step in my calculations...

Alright, you win. But I would recommend to not store serials inside the plugin (unnecessary loading time for parsing ten of thousands of JSON strings, possibility of license overflow), but to just check them with any arbitrary logic:

isSerialValid(decryptedSerial)
{
    return decryptedSerial.charAt(4) = 'A'; // or something a bit more secure...
}

then only generate serials that match against that filter in your keygen.