Cryptography problem

Discussion in 'Computer Security' started by Dean Hallman, Jun 22, 2004.

  1. Dean Hallman

    Dean Hallman Guest

    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?
    Dean Hallman, Jun 22, 2004
    #1
    1. Advertising

  2. Dean Hallman

    Ken Guest

    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" <> wrote in message
    news:us2Cc.65466$...
    > 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?
    >
    >
    Ken, Jun 23, 2004
    #2
    1. Advertising

  3. Dean Hallman

    Mailman Guest

    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
    Mailman, Jun 23, 2004
    #3
  4. 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
    Lassi =?iso-8859-1?Q?Hippel=E4inen?=, Jun 23, 2004
    #4
  5. Dean Hallman

    Gerard Bok Guest

    On Tue, 22 Jun 2004 22:32:58 GMT, "Dean Hallman"
    <> 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
    Gerard Bok, Jun 23, 2004
    #5
  6. Dean Hallman

    Bill Unruh Guest

    (Gerard Bok) writes:

    ]On Tue, 22 Jun 2004 22:32:58 GMT, "Dean Hallman"
    ]<> 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
    Bill Unruh, Jun 23, 2004
    #6
  7. Dean Hallman

    Dean Hallman Guest

    >
    > 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
    Dean Hallman, Jun 23, 2004
    #7
  8. Dean Hallman

    Dean Hallman Guest


    > 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
    Dean Hallman, Jun 23, 2004
    #8
  9. 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
    Eugene Mayevski, Jun 23, 2004
    #9
  10. In article <Xns95117D739FEEDdeanhscrrcom@24.25.9.43>,
    Dean Hallman <> 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,
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Margolin, Jun 24, 2004
    #10
  11. Dean Hallman

    Tracker Guest

    Try cryptography message boards instead of Usenet, or try Steganography message
    boards.

    Thanks for the lesson.

    Tracker


    Ken wrote:

    > 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" <> wrote in message
    > news:us2Cc.65466$...
    > > 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?
    > >
    > >
    Tracker, Jun 24, 2004
    #11
  12. Dean Hallman

    Gerard Bok Guest

    On Wed, 23 Jun 2004 16:24:44 GMT, Dean Hallman <>
    wrote:

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

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


    'out of sync' need not pose any problems, as you can define a
    window to accomodate that situation.

    How would your server distinguish between a client being
    reinstalled on the same machine from that client being installed
    on 10.000 hacked machines (as was your original problem, wasn't
    it) ?

    Re-authorizing after reinstall seems a modest requirement.
    You either implement a secure identification system or you don't
    :)

    --
    Kind regards,
    Gerard Bok
    Gerard Bok, Jun 24, 2004
    #12
  13. Eugene Mayevski wrote:
    >
    > 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.


    Looks like a beginning of a threat model. Are only external enemies your
    worry, i.e. do you trust your true clients?

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


    Unfortunately there is a man-in-the-middle workaround to graphic
    challenges. The attacker needs only to install a service that has a
    constant supply of innocent human users. The challenge (text as image)
    can then be relayed to a real person, and the response is relayed back
    to the original challenger.

    -- Lassi, getting back to summer vacation...
    Lassi =?iso-8859-1?Q?Hippel=E4inen?=, Jun 26, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lord Shaolin
    Replies:
    0
    Views:
    454
    Lord Shaolin
    Sep 28, 2003
  2. Dawnbell

    RSA cryptography

    Dawnbell, Nov 5, 2003, in forum: Computer Security
    Replies:
    3
    Views:
    519
    John D Loop
    Nov 6, 2003
  3. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "Practical Cryptography", Bruce Schneier/Niels Ferguson

    Rob Slade, doting grandpa of Ryan and Trevor, Nov 17, 2003, in forum: Computer Security
    Replies:
    0
    Views:
    538
    Rob Slade, doting grandpa of Ryan and Trevor
    Nov 17, 2003
  4. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "Cryptography and E-Commerce", Jon C. Graff

    Rob Slade, doting grandpa of Ryan and Trevor, Nov 28, 2003, in forum: Computer Security
    Replies:
    0
    Views:
    603
    Rob Slade, doting grandpa of Ryan and Trevor
    Nov 28, 2003
  5. Rob Slade, doting grandpa of Ryan and Trevor

    REVIEW: "RSA and Public Key Cryptography", Richard A. Mollin

    Rob Slade, doting grandpa of Ryan and Trevor, Dec 18, 2003, in forum: Computer Security
    Replies:
    0
    Views:
    493
    Rob Slade, doting grandpa of Ryan and Trevor
    Dec 18, 2003
Loading...

Share This Page