RSA encryption - practical question

Regards everybody,

I'm distributing an application that needs a licence file protection. A file
comes with a registered version that contains encrypted customer data. It's
encrypted using asynchronous encryption (RSA).

The idea is to encrypt the file with a private key, and give the public key
to the application. So the application could decrypt the file, but would not
be able to encrypt it. The goal is to make it as difficult as possible to
make a keygen that would work on unmodified application assembly (with the
original, unpatched exe that contains the unmodified public key).

I planned to do this by separating public and private keys, and giving only
the public key part to the application.

1. I don't know if it is possible to decrypt using only the public key, so
that's my first question. Can I switch public and private keys this way ?
Can the user decrypt using only the public key ?

2. Second question (given the premise that we're not modifiying the assembly
or memory during runtime): Is this idea good ? Would it be secure ?

Re: RSA encryption - practical question

Lucius wrote:
> The idea is to encrypt the file with a private key, and give the public key
> to the application. So the application could decrypt the file, but would not
> be able to encrypt it. The goal is to make it as difficult as possible to
> make a keygen that would work on unmodified application assembly (with the
> original, unpatched exe that contains the unmodified public key).

The keygen will not be the problem. The executable itself will be.
It will be possible to modify it, so it does not need to check any
key any more.

> 2. Second question (given the premise that we're not modifiying the assembly
> or memory during runtime): Is this idea good ? Would it be secure ?

No. No.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: RSA encryption - practical question

Yikes. Though I'm a fan of RSA as a seed key exchanger, this might be
a bit over the top. In order to certify this you would have to add a
hash function. Now, if we only had a white board where we could draw
this out. But even at that, it would still be a bad implimentation.

Re: RSA encryption - practical question

Sorry guys I was off for a few days. Thank you for your posts.

I don't understand what you mean. By hashing you mean signing ? That I
understand, and if noone could change the EXE, this would teoretically work
pretty fine.

However it's only a matter of skipping an IF in the assembly when you want
to crack it.

I did some extra thinking about how to solve this problem. Since it allways
breaks down to skipping a few instructions in the program, the best solution
I can think of now is to make a custom algorithm: some byte-shuffling, then
some symetric encription, and many combinations over and over until I get
really bored. This is crackable of course, and it's not a science to crack,
but the fact is that if someone wants to make a licence generator, he/she
would have to take some extra time to do it. You can't skip anything in the
program, because then it won't decrypt and won't work, so you have to go
through the algorithm and understand it (decompile it, gather the symetric
keys, etc.) to be able make another file. I can combine it with some RSA
signing to add extra work to the cracker, and obfuscate the code.

The problem with hasing is that it's very good when someone _wants_ to check
if data came from a certain source and is unmodified, and RSA does a great
job here. But I don't see how it could help in my case. The cracker just
skips the procedure that checks if the license file is genuine, and that's
it. The program doesn't _need_ the RSA hashing to decrypt the file, just to
check if it's origins and contents are okay.

If I'm missing something please point me in the right direction. Or if you
have a another idea...

Thanks,
Lucius


"Wade" wrote in message
news:1142529067.215111.254810@e56g2000cwe.googlegroups.com.. .
> Yikes. Though I'm a fan of RSA as a seed key exchanger, this might be
> a bit over the top. In order to certify this you would have to add a
> hash function. Now, if we only had a white board where we could draw
> this out. But even at that, it would still be a bad implimentation.
>