Different Encryption Types in HISE?

[Casmat]

Hey!

I'm wondering what are the supported Encryption Types (like SSH Keys) in HISE, i've seen Blowfish and RSA, but is it possible to add support for more modern types such as EdDSA (Ed25519 in particular) which both have faster performance and shorter key signatures?

Thanks!

[Christoph Hart]

@Casmat is there a particular use case where you hit an actual limitation? I never found the performance to be a real world problem with the little amount of data that needs to be encrypted.

[Lindon]

@Christoph-Hart well ignoring performance - the shorter keys and the improved security would be good.

[Casmat]

@Christoph-Hart agree with @Lindon! ed25519 has a length of 256 but has the security of a rsa 3048 key

[ustk]

@Christoph-Hart Don't know anything about this encryption, but if it can shorten the computation time significantly against the RSA2048 I'm definitely favourable to this change...

[Christoph Hart]

@ustk But when is this becoming a problem? Encoding a license key with a few hundred bytes is completely trivial and will never be a bottleneck and for big data you can use Blowfish?

[Casmat]

@Christoph-Hart yeahhh, rsa doesn’t have any true limitation, it’s just the optimization/modernization that ed25519 has that makes it appealing

[Lindon]

@Christoph-Hart said in Different Encryption Types in HISE?:

@ustk But when is this becoming a problem? Encoding a license key with a few hundred bytes is completely trivial and will never be a bottleneck and for big data you can use Blowfish?

it becomes a problem when the plugin wants to use a simple dont-call-home serial number system - we need to encrypt this in some way, and RSA 512 is too weak (apparently) so we use RSA 2048 - which yields a very long string for the user to enter...so any system that is as capable as RSA2048 but offers a smaller string for the end user to work with would be nice.

[ustk]

@Christoph-Hart On my end I use the PHP script you posted a while ago on the juce forum to encrypt the license. Using a 2048bit key takes approx. 10-15sec for the server to perform this task which seems a wee bit long.

Is the server too weak? I don't think so
Is the PHP script not optimised? Maybe...

[Dan Korneff]

@ustk said in Different Encryption Types in HISE?:

10-15sec for the server to perform this task

That sounds inane. I have a PHP script that took .3 seconds to execute, and it destroyed my server at scale.

[ustk]

@Dan-Korneff

[ustk]

@Christoph-Hart Just ran some tests:

2048 -> 10sec
1024 -> 3sec
512 -> 1.5sec

Of course, these are the total times from plugin license manager demand to license file reception. But seeing the timing at 512bit, the transaction time is negligible.

[Lindon]

@ustk could you also list the size of your generated key? Interested to find out if the encrypted key you send is bigger or smaller for each bit size...

[ustk]

@Lindon
2048 bit-> 2048 chars
1024 bit -> 1790 chars
512 bit -> 1658 chars

But I guess it's dependant on the size of the data you want to encrypt in the first place

[orange]

@Dan-Korneff said in Different Encryption Types in HISE?:

@ustk said in Different Encryption Types in HISE?:

10-15sec for the server to perform this task

That sounds inane. I have a PHP script that took .3 seconds to execute, and it destroyed my server at scale.

Considering that we are giving free products (even for a limited time, for the launch for example), hundreds, maybe thousands of users will attack the server for authentication. The server is fucked then :)

[d.healey]

@orange Yup, I just see everyone trying to put bigger locks on a half open door. If someone wants in they don't care if it's 512 or 2048, they can get in anyway.

[Lindon]

@d-healey said in Different Encryption Types in HISE?:

@orange Yup, I just see everyone trying to put bigger locks on a half open door. If someone wants in they don't care if it's 512 or 2048, they can get in anyway.

yeah, thats not really understanding the problem or the proposed solution.

You are right the door is half open.
You are not so right regarding 512 vs 2048

2048 - means they have to modify the code base
512 - means they can reverse engineer the private key and build a keygen

Any system that requires modifying and shipping a "hacked" version is better than one that only requires shipping a small key gen program and pointing the hackers thief-friends at our servers to download the demo version

BOTH these solutions remove the scriptless-kidddies who just steal any un-serialised versions in the first 1-2 days..so they are out of the picture

..so yes both bit sizes requires the hacker to be at least reasonably competent, but 2048 means more work for them (always a good thing) - not in the hacking effort - but in the shipping effort.

[d.healey]

@Lindon said in Different Encryption Types in HISE?:

BOTH these solutions remove the scriptless-kidddies who just steal any un-serialised versions in the first 1-2 days

You guys must be doing something I'm not. I've been selling open source sample libraries without any kind of copy restriction for 5 years and I haven't seen anyone giving away copies. I'm feeling left out now that my stuff isn't turning up on these "pirate" stores.

[Lindon]

@d-healey said in Different Encryption Types in HISE?:

@Lindon said in Different Encryption Types in HISE?:

BOTH these solutions remove the scriptless-kidddies who just steal any un-serialised versions in the first 1-2 days

You guys must be doing something I'm not. I've been selling open source sample libraries without any kind of copy restriction for 5 years and I haven't seen anyone giving away copies. I'm feeling left out now that my stuff isn't turning up on these "pirate" stores.

I'd guess it's your audience Dave, try doing a DubStep/Grime synth and see how far you get...

[Christoph Hart]

@Lindon I think dave is right with his bigger lock on a half open door though. The attack vector is most likely not reverse engineering the private key but simply remove that check or replace the public key in the plugin with another one that matches the private key of the keygen.

In order to reverse engineer the private key you have to extract it and then run brute force stuff for a certain amount of time, but as soon as you know where to find the public key in the binary application file, you can as well just modify it and save the CPU cycles required for brute forcing that private key.