On 2010-08-27 16:48 PDT, Michael Smith wrote: > We're not really looking for a "couldn't be compromised" solutions - > this is a requirement from a company we're partnering with, not our > idea, and they basically just want it to not be "simple" (for some > value of that) to compromise. So: serialising it to disk without some > sort of encryption isn't ok, and exposing it in exportable form in the > browser UI isn't ok.
What is the real underlying objective of this? Is it to authenticate the individual user of the product to the servers? Is it to ensure that the client applications of the network service are genuinely those made by your "partner", and not some other client that has been made by some third party who reverse engineered your protocol? (e.g. as AOL used to try to ensure that only genuine AOL clients accessed the AOL Instant Messenger servers?) Is it something else? The use of public key certificates may not be the best way to accomplish your objective, or even an appropriate way at all, but we cannot determine that until we know what that objective is. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
