> I'm passing some data through a web client [applet-like] and am planning > on using some crypto to help ensure the data's integrity when the applet > sends it back to me after it has been processed.
Help us to understand your threat model. Do you trust the user and his/her machine, but are worried about Mallory altering the communications between client and server? Do you need confidentiality too, or just integrity? How serious an attacter are you concerned with? Curious and semi-technical? Determined hacker? NSA? > Is it better to have the key encoded in the binary, or to pass it a > plain text key as one of the parameters to the applet? Both strategies seem like doom to me. Either way, the key is in a form which allows Eve or Mallory to learn it. You need to find a way to keep from sending the key in the clear. What about using Diffie-Hellman key exchange? What about SSL? Depending on your needs, SSL might be overkill, but it has the advantage of having been prodded quite a bit at the protocol and (often) implementation level. SSH may be an option too. Is the web client sent to the user over HTTP? Can you ensure that the connection uses SSL? If so, the key does not have to travel in plaintext form. There is still the issue of key re-use. How much control do you have over the server from which the java client is sent? You could send a different symmetric key with each client, though that is a little strange. A better strategy might be to send a private key with the client which it can then use to negotiate session keys with the server. Having said all that, I still lean towards using a library with an existing protocol like SSL or SSH. Whether either of those is applicable really depends on the specifics of your app, to whom it is distributed, etc. --mkb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
