Re: Cryptography problem

From: Dean Hallman (deanh_at_sc.rr.com)
Date: 06/23/04

  • Next message: Dean Hallman: "Re: Cryptography problem" 
    Date: Wed, 23 Jun 2004 16:19:59 GMT

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

  • Next message: Dean Hallman: "Re: Cryptography problem"

    Relevant Pages

    • Re: Cryptography problem
      ... Okay, I'll post there in the future. ... The encryption method cannot be kept secret, ... > in the hands of the attacker. ... > I suggest you first figure out your threat model, ...
      (alt.computer.security)
    • RE: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning
      ... Okay, so goal of libmalware.so is to "not allow data in the black list ... to pass through Linux server". ... That's only part of the threat model. ...
      (Linux-Kernel)
    • Re: Network Security
      ... but not easily (unless the attacker finds it some other way.) Each ... >person should consider his threat model and act accordingly. ... Geoff Lane ...
      (comp.os.linux.networking)
    • Re: "incrementing" ecb mode
      ... What is your threat model? ... Can an attacker choose plaintexts ... or crypttexts? ... > long as an attacker cannot insert known, ...
      (sci.crypt)