another take/facet on signing & authentication ... from thread in sci.crypt ng http://www.garlic.com/~lynn/2002p.html#52 http://www.garlic.com/~lynn/2002p.html#50
note that their is periodically an issue raised regarding using the same token/keypair in multiple environments. fundamentally at the basis is the existing practice based existing procedures involving shared-secrets. it is obvious that using shared-secret based keys, pins, numbers, and passwords (either instantiated as tokens or magstripe cards, or memory) in multiple different (security) contexts represents a risk. such risks justify (from a security standpoint) the requirement for a unique token for every unique security context (every different financial institution, every different ISP, every different employer, etc). Envisoning a feature, token-based security environment ... a person might require large tens of such tokens. it is pretty obvious that a public key used in multiple different (security) contexts is free of the impersonation risks that come with shared-secred based paradigm. harvesting information from a merchants credit card transaction file enables a crook to perform fraudelent transactions ... somewhat related http://www.garlic.com/~lynn/2001h.html#61 aka in a shared-secret paradigm the same information that is used to originate a transaction is used to validate a transaction ... as a result the accumulation of such information represents a threat/risk. the use of public key non-shared-secret paradigm alliviates that particular risk/exploit mode. there is a business question regarding aggregation of everything into a single token .... where the electronic failure of that single token leaves the individual w/o financial and/or other recourse. this would tend to support a personal choice for having two or three tokens and spreading various business purposes across the tokens (each token having at least some financial capability). there have been some hypothetical arguments for multiple tokens as risk mitigation because of token theft exploits ... however these tend to much more of a red herring. assuming an iso7816 smartcard hardware token scenario ... a person carries all of their tokens in their wallet or purse. The common unit of (physical) loss/theft is the wallet or purse ... not individual tokens. The advocation of multiple tokens as risk mitigation for loss/theft exploits is only valid if the tokens are distributed in such a way that they wouldn't commonly all be lost/stolen at a single time. as in other areas .... theat counter measures (aka risk mitigation) need to correspond with realistic threat/risk scenarios.
