Re: Cryptography problem

From: Lassi Hippeläinen (lahippel_at_ieee.orgies.invalid)
Date: 06/23/04 

Date: Wed, 23 Jun 2004 09:21:21 GMT

Dean Hallman wrote:
>
> I have what I believe is a bit unique as cryptography problems go. I was
> hoping someone on this board might be able to offer some advice or pointers
> to a suitable crypto solution.

FYI: the place to ask about cryptography is sci.crypt.

> Basically, I have a web server that can process search strings, and clients
> that submit search strings.
>
> However, the client software must be *my* software (rich clients). I don't
> want imposters, masquerading as my software and sending search packets the
> server can't distinguish from my own

You have no way of making sure the other end runs your software, unless
you distribute it with a *tamperproof* hardware dongle. But why would
you insist on your own software? What is your threat model?

> So, I need to packetize and encrypt the search string in my rich clients and
> send it across the internet to the server, without hackers figuring out the
> packet format and encryption method.
>
> So, a search request would contain:
>
> [ UserName, password, "search string" ]

If an eavesdropping third party is your only threat (i.e. you trust the
clients), any properly authenticated and encrypted session (IPSec, ssh,
SSL, TLS, ...) is secure enough. There is no need to pass the username
and password in each request, if the session is already authenticated.

> So, a hacker can figure out the original data being encrypted. Doesn't that
> compromise my encryption method? If you know the original data, can't you
> reverse engineer the encryption method?

Any modern encryption algorithm is secure against known plaintext
attacks. The encryption method cannot be kept secret, if the device is
in the hands of the attacker. If the application is important enough,
the attacker can get a copy of the client anyway, sooner or later, so
you can't trust on keeping the method secret ("security by obscurity").

> I know I could add less obvious stuff to the packet, but I don't think that
> adds much security. People will still eventually guess the packet contents
> and layout.
>
> So,
>
> Q: How can I keep the encryption method secure (non-reproducable), while at
> the same time, exposing for all to see the payload being encrypted?

The encryption methods are public anyway. Security is based on keeping
the key secret (Kerckhoffs' Principle).

I suggest you first figure out your threat model, and choose the method
only after it is clear. Starting from methods before thinking about
threats is as misleading as owning a hammer and seeing all problems as
nails.

-- Lassi