Re: Crypting data

Hello Will

thanks for your answer.

I need to transfer license data to the customer.This is a normal
cycle:
- costomer creates a license request including name and cpuID
- customer sends that file to me
- i create a license file for that specific cpu-id and name
- i send the license to the customer.

First of all i know this is not secure in means of beeing cracked,
independently of what technic i use. The easyest way for the customer
to break the code would be to install the requiered software under
VMware and he would not "have any longer any problems".
But we are talking of some 200 lets say "noob" users which will not do
big cracking sessions :)
For most users it would be enough to Base64 encode the data so its not
readable. But i'd like to add just a little more "security" or better
sayed difficulties for them do change the license data.
Also at the moment i'm allready using an signed-xml document that i do
use to ensure that the data is comeing from me (i order for the
customer to be sure the data is coming from me).

Any suggetions?

On 28 Feb., 00:29, Will Dickson <w...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
On Tue, 27 Feb 2007 13:49:16 -0800, rene.marxis wrote:
Hello

i have some simple questions on crypting. I like to encrypt some data i
send to some customer and i'd like to ensure no one is able to
create/encrypt the data except me.

Are you sure that's what you need?

Either someone can create the data, or they can't - cryptography won't
make a difference either way. Similarly, once somebody's created the data
in question, there's no way you can prevent them from encrypting it if
they feel like it.

If you're looking for a DRM scheme (whereby you try to dictate what the
customer can do with the data once you've sent it to them) my suggestion
would be to look for a different business model. It *will* get cracked.

If, on the other hand, what you want is some means whereby the customer
can verify that the data is coming from you and not some impostor, then
cryptography can help you. What you're looking for in this case is called
"public key" cryptography.

Two pieces of advice:

1. Use the standard. It's called "X.509" and it's got nasty big teeth.

2. If this is for *anything* involving money, get someone else to build it
for you. This crypto stuff is a *lot* harder to get right than it looks,
you're not ready, and it'll take you a long time to get ready. (Please
don't take that as a personal attack - it isn't intended as one.) The
problem with security-critical code in general, of which crypto code is a
subset, is that - unlike most other kinds of code - you can't tell whether
you got it wrong until somebody breaks it and leaves you holding a large
bill / lawsuit.

HTH

Will.


.