Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Cryptography problem

Reply
Thread Tools

Cryptography problem

 
 
Dean Hallman
Guest
Posts: n/a
 
      06-22-2004
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?


 
Reply With Quote
 
 
 
 
Ken
Guest
Posts: n/a
 
      06-23-2004
Dean, random padding would help at the start, and or end of your packet
or, you could simply use SSL and get it to do authentication using
certificates or something like that.

Ken

"Dean Hallman" <(E-Mail Removed)> wrote in message
news:us2Cc.65466$(E-Mail Removed). com...
> 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?
>
>



 
Reply With Quote
 
 
 
 
Mailman
Guest
Posts: n/a
 
      06-23-2004
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
 
Reply With Quote
 
Lassi =?iso-8859-1?Q?Hippel=E4inen?=
Guest
Posts: n/a
 
      06-23-2004
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
 
Reply With Quote
 
Gerard Bok
Guest
Posts: n/a
 
      06-23-2004
On Tue, 22 Jun 2004 22:32:58 GMT, "Dean Hallman"
<(E-Mail Removed)> wrote:


>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


Maybe tickets solve your problem ?

You ship each of your rich clients with a unique ticket.
Each request validates the ticket, supplies an answer, and a new
ticket, to be used for the clients next request.
You could even use the ticket as an encryption key to part of the
message.


--
Kind regards,
Gerard Bok
 
Reply With Quote
 
Bill Unruh
Guest
Posts: n/a
 
      06-23-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Gerard Bok) writes:

]On Tue, 22 Jun 2004 22:32:58 GMT, "Dean Hallman"
]<(E-Mail Removed)> wrote:


]>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

]Maybe tickets solve your problem ?

]You ship each of your rich clients with a unique ticket.
]Each request validates the ticket, supplies an answer, and a new
]ticket, to be used for the clients next request.
]You could even use the ticket as an encryption key to part of the
]message.

Sounds like a great way of really annoying your rich clients, as they loose
the tickets, etc. Ie, it is thier machine that must keep track of the
ticket, and who knows what happens on their machine.

You could use IP linking-- ie the request must come from their IP (which
maeks it useable only on one machine). You could stick a challenge response
into the software, but of course that could be worked around by a smart
hacker
 
Reply With Quote
 
Dean Hallman
Guest
Posts: n/a
 
      06-23-2004
>
> FYI: the place to ask about cryptography is sci.crypt.


Okay, I'll post there in the future.

> You have no way of making sure the other end runs your software,
> unless you distribute it with a *tamperproof* hardware dongle.


Oh.. I hope I can avoid a dongle.


> But why
> would you insist on your own software? What is your threat model?


First, this is a niche search engine supplying information specific to a
particular industry.

Second, it will offer incentives for each search submitted.

Third, I need to stop automation software from entering bogus searches
programmatically to gain incentives for the hacker.

So, it doesn't necessarily have to be my software, as long as the
request is authentic and not automated (actually entered in real time by
a human at a keyboard). But, I believe the only way I can assure the
later it by being the client.


> 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.


Got it.

> 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").


Okay.. Good point. Hadn't thought of it that way.



> 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.
>


Did my earlier explaination of my threat model serve as sufficient
understanding? I believe this part is understood, but your point is
well taken.

Thanks,
Dean
 
Reply With Quote
 
Dean Hallman
Guest
Posts: n/a
 
      06-23-2004

> Maybe tickets solve your problem ?
>
> You ship each of your rich clients with a unique ticket.
> Each request validates the ticket, supplies an answer, and a new
> ticket, to be used for the clients next request.
> You could even use the ticket as an encryption key to part of the
> message.


Yes, I had considered something similar to this. But, connect the current
search with the next search in this way could lead to "out of sync"
problems. What if the client is uninstalled and reinstalled, for example.
The ticket for use on the next search could be lost.

Dean
 
Reply With Quote
 
Eugene Mayevski
Guest
Posts: n/a
 
      06-23-2004
Hello!
You wrote on Wed, 23 Jun 2004 16:19:59 GMT:

DH> Third, I need to stop automation software from entering bogus searches
DH> programmatically to gain incentives for the hacker.
DH> So, it doesn't necessarily have to be my software, as long as the
DH> request is authentic and not automated (actually entered in real time
DH> by a human at a keyboard). But, I believe the only way I can assure
DH> the later it by being the client.

Then you need to look at different methods of distinguishing the human user
from automated software. The most popular method, as you know, is asking the
person to enter some text shown as an image.

Unfortunately this seems to be the only way to protect from automated
clients.

With best regards,
Eugene Mayevski

 
Reply With Quote
 
Barry Margolin
Guest
Posts: n/a
 
      06-23-2004
In article <Xns95117D739FEEDdeanhscrrcom@24.25.9.43>,
Dean Hallman <(E-Mail Removed)> wrote:

> So, it doesn't necessarily have to be my software, as long as the
> request is authentic and not automated (actually entered in real time by
> a human at a keyboard). But, I believe the only way I can assure the
> later it by being the client.


Many systems provide ways to feed keystrokes to programs, so that users
can automate the use of GUI-based applications. So even if it's your
program sending the requests, it could still be automated.

As someone else mentioned, the only way to really be sure there's a
human involved is to require them to do something only a human is able
to do, like read a fuzzy word.

--
Barry Margolin, (E-Mail Removed)
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Programming Cryptography in J2SE 1.3.1 Zheng Da Java 2 04-29-2006 02:47 PM
Re: "System.Security.Cryptography.CryptographicException: Bad Data" Message Dei401 ASP .Net 0 02-02-2005 04:30 PM
Generating hashes (System.security.cryptography) Mauricio Correa L. ASP .Net 1 06-18-2004 01:45 PM
cryptography library a_the_s@hotpop.com C++ 1 11-02-2003 10:42 PM
cryptography software Apple Java 1 10-12-2003 09:39 AM



Advertisments