crypto/web impementation tradeoffs

[bear]

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 majordomo at wasabisystems.com
>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com