Re: Cryptography problem

• Previous message: Ken: "Re: Cryptography problem"
• In reply to: Dean Hallman: "Cryptography problem"
• Next in thread: Dean Hallman: "Re: Cryptography problem"
• Reply: Dean Hallman: "Re: Cryptography problem"
• Reply: Dean Hallman: "Re: Cryptography problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 23 Jun 2004 05:35:07 +0200

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.
>
> 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
>
> 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" ]
>
> 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?
>
> 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?

This is known as the "known plaintext" problem, and modern cryptosystems are
pretty much immune to it (since Kasisky's days it has been an axiom that
the security of a system depends only on the key - even if the attacker
knows the exact encryption algorithm and contents being sent). BTW - why
would you need to send the user name/password as part of the request?

Replay attacks (reusing a request without knowing what it means): this is
usually dealt with by adding random padding and timestamps/counters/unique
tokens to the request. Modern systems would use something like a public key
system to negotiate an ephemeral session key which is then used to encrypt
the whole channel.

That being said, crypto is HARD: you are very likely to get it wrong the
first few times around. Your best bet: use HTTPS (OpenSSL is excellent) and
have the whole channel encrypted. People put a lot of effort into
developping the library and there really is no need to reinvent the wheel.

-- 
Mailman

• Previous message: Ken: "Re: Cryptography problem"
• In reply to: Dean Hallman: "Cryptography problem"
• Next in thread: Dean Hallman: "Re: Cryptography problem"
• Reply: Dean Hallman: "Re: Cryptography problem"
• Reply: Dean Hallman: "Re: Cryptography problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]