HISE RSA Not Working

[ustk]

I confirm creating the key pair from Hise is the way.
The 2048 length works, I did add the option for better security since cracking a 512 key seems quite easy nowadays (at least following my research) but the server load (using my own PHP plugin) to encrypt my licenses is huge with a 2048bit key (512 is fast, 1024 is acceptable), am I the only one to have this issue?
Does anyone using Hise Activate encounter a noticeable delay too when using a 2048 key?

[Casmat]

@ustk yeah 2048 is minimum for todays world and it does take a couple seconds to sign due to its size, this is where rsa reaches its annoyances, hence why there’s modern options (ed25519 algorithm) which have both shorter signatures, faster performance, all while getting more security.

[ustk]

@Casmat Hence my current personal interrogation about moving this encryption to a specific server so to release the load from the website...

[d.healey]

Can't this just be defeated by switching an if statement within the binary anyway?

[ustk]

@d-healey Not when using the Unlocker system which is deeply embedded in the binary. I believe this is the best protection Hise (Juce) offers so far...

[Casmat]

@ustk hmm, what’s this unlocker system im seeing, Is it just meant for HISE Activate or how do I work with it?

[ustk]

@Casmat

https://docs.hise.audio/scripting/scripting-api/unlocker/index.html

I'm not sure there's a dedicated thread about this but if you search the forum you'd find some examples...

Hise activate is a ready made server for the encryption so you just have to worry about your plugin implementation side, but you might roll your own PHP script own your server if you feel it
there's a PHP example somewhere around...

[ustk]

here:
https://forum.hise.audio/topic/5369/build-failed-with-copy-protection-enabled?_=1704891683446

[Lindon]

@d-healey said in HISE RSA Not Working:

Can't this just be defeated by switching an if statement within the binary anyway?

yes - or a number of if statements if you've coded it that way. All this is doing is

1. stopping the script kiddies on day-0
2. stopping the pro-pirates building a keygen

So these are the two worst scenarios for reducing sales.

So can this be hacked ?- why of course it can, anything can be hacked eventually, but this requires the pirate to hack your code base and distribute their own copy of your product. At that point you are pretty much where Urs is at with UHe. Sure he's using a more sophisticated series of counter-measures but the single most important counter measure (he says) is to release updates often -1.1,1.2,1.3 etc. forcing the pirate thru the hoop one more time.

Should you use 2048-bit keys - well, 512-bit stops issues 1 & 2 above so really its hard to see the point.
Any pro hacker(as you rightfully point out) will just circumvent your serial-checking code in all the places they can find it making the actual algo. pretty moot, as long as they cant reverse engineer your checking code (and using RSA stops that as they cant generate your private key)

[ustk]

@Lindon said in HISE RSA Not Working:

(and using RSA stops that as they cant generate your private key)

unless 512 is "easily" hackable, right? Hence the 2048 size
because if a hacker can easily hack a 512 key there's no point in building the most protective code

[Casmat]

@ustk thanks! Looks like the unlocker is mainly meant for online licensing solutions. We’re currently planning to release a version with a simple offline auth system using ssh keys to encrypt and make the user download a license.dat file and import that along with the installer into the plugin to verify the license

[Casmat]

@ustk 512 can be cracked in a couple days with decent hardware, possibly hours with good hardware. 2048 is estimated to be crackable in trillions of years

[Lindon]

@ustk said in HISE RSA Not Working:

@Lindon said in HISE RSA Not Working:

(and using RSA stops that as they cant generate your private key)

unless 512 is "easily" hackable, right? Hence the 2048 size
because if a hacker can easily hack a 512 key there's no point in building the most protective code

yeah - EdDSA seems to be the way to go...if you want it secure - buit really the last hour has told me I know nearly nothing about asymmetric encryption...