crypto/web impementation tradeoffs
Hi 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. The applet has the ability to encode data with several well known symmetric ciphers. The problem I'm having has to do with key management. 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? I know that the way most cryptosystems work is that the security is in the key. But having a compiled-in key just seems like a time bomb that's going to go off eventually. Is it better to have a variable key passed in as data [i.e. not marked as key] or to have a static key that sits there and waits to be found. Thanks. -- \js 'People who work sitting down get paid more than people who work standing up.' - Ogden Nash (1902-1971) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto/web impementation tradeoffs
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]
Re: crypto/web impementation tradeoffs
Without more knowledge of the parameters of the system (especially the threat model), it's hard to say -- however, this sounds like a case for the Diffie-Hellman key agreement protocol. Have the client and server each pick a random number, and then use those numbers to generate a key dynamically. Bear On Wed, 3 Jul 2002, John Saylor wrote: Hi 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. The applet has the ability to encode data with several well known symmetric ciphers. The problem I'm having has to do with key management. 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? I know that the way most cryptosystems work is that the security is in the key. But having a compiled-in key just seems like a time bomb that's going to go off eventually. Is it better to have a variable key passed in as data [i.e. not marked as key] or to have a static key that sits there and waits to be found. Thanks. -- \js 'People who work sitting down get paid more than people who work standing up.' - Ogden Nash (1902-1971) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: crypto/web impementation tradeoffs
John Saylor wrote: Hi 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. The applet has the ability to encode data with several well known symmetric ciphers. The problem I'm having has to do with key management. 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? I know that the way most cryptosystems work is that the security is in the key. But having a compiled-in key just seems like a time bomb that's going to go off eventually. Is it better to have a variable key passed in as data [i.e. not marked as key] or to have a static key that sits there and waits to be found. If all you want to ensure is integrity, why are you using symmetric encryption? Surely a keyed HMAC would make more sense? Not that this changes your question. However, you haven't specified your threat model, so I feel unable to answer. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
