Perry E. Metzger wrote: > Even in totally ordinary circumstances it is important to have very > strong signing keys. Your comments were insupportable.
there is a somewhat separate issue having to do with security proportional to risk. minor old posting: http://www.garlic.com/~lynn/2001h.html#61 the security acronym PAIN P ... privacy (or sometimes CAIN and conficentiality) A ... authentication I ... integrity N ... non-repudiation part of the problem is that sometimes confusion between digital signatures and human signatures (implying read, understood, agrees, approves, and/or authorizes). the technology is asymmetric keys .... involving a pair of keys, what one key encodes, the other key decodes (differentiates from symmetric key encryption where the same key is used for encryption and decryption). there is a business process commonly referred to as public key where one key of a asymmetric key pair is identified as public and made available. the other key is identified as private, kept confidential and never divulged. there is a business process called digital signatures where a hash of some message or document is computed and then encoded. the message/document is sent off with the appended digital signature. the recipient recomputes the hash of the message/document and decodes the digital signature with the corresponding public key. if the two hashes compare, then the recipient (or relying party) can assume: 1) the message/document hasn't changed since transmission 2) the message/document has been authenticated as originating from the entity associated with the public key. the amount of risk is associated with the risk of attack on the corresponding message/document. say the digital signature operation is used for authenticating x9.59 transactions http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 that happen to be credit card transactions where the account owner has a credit limit of $1000, all transactions are online against the account, the account public key can be deactivated when there appears to be fraud and to the consumer the frauulent transactions can be reversed (leaving the consumer with a maximum $50 exposure). the existing infrastructure has no real authentication operation except for attempting to maintain the account number as a shared secret (which implies that the account number ... rather than any public key ... has to be deactivated & replaced when there has been compromise): http://www.garlic.com/~lynn/subpubkey.html#secret some postings on account number skimming/havesting http://www.garlic.com/~lynn/subpubkey.html#harvest some postings on fraud & vulnerabilities http://www.garlic.com/~lynn/subpubkey.html#fraud compared to some of the other payment card operations that specified public key authentication ... x9.59 allowed for 1) digital signature authenticated transactions 2) account number used in authenticated transactions could not be skimmed and used in non-authenticated transactions (which some of the other specifications allowed) ... basically countermeasure to form of replay attacks and countermeasure for having to treat account number as shared-secret. the basic issue in both (digital signature) signing keys and encryption keys is what is the risk from a compromise and based on that risk you can determine the level security required. another consideration is the overall infrastructures. for many of the online e-commerce operations ... an ECC 163-bit signing key probably has a lot higher security strength than the rest of the infrastructure used to protect the signing key and/or the environment where the digital signature is applied. from an attackers standpoint that means that it is probably cheaper/easier to attack the infrastructure to capture the signing key ... than to try a brute-force attack on the signing key (and all of these other attacks are applicable regardless of the strength of the signing key). there may also be attacks on other parts of the infrastructure ... getting the financial institution to register a new public key (belonging to the attacker) or getting a certification authority to issue a new certificate with the attacker's public key in the name of the victim. some of these other operations may be currently weak because the claim is that they aren't currently the weakest link in overall infrastructure. there may be other trade-offs. it is possible to get reasonably priced 14443 contactless tokens that can do ecc 163-bit digital signing in subsecond time that may be desirable in various POS or transit turnstyle operations. going to larger key sizes may exceed both the power requirement and the elapsed time requirement (in contact token operatin you can someimes trade-off peak power draw against onger elapsed time). The case can be made in some scenarios ... that the longest possible keylength be chosen if the power and elapsed time requirements aren't a major factor. However, there can be environments where power and elapsed time requirements may justify choosing a shorter keylength (within the context of the overall environment) one of the things that payment card infrastructures have the ability to do is a real time risk evaluation on a per transaction basis and pass judgement on a wide variety of factors which might include ... key length, whether there is a certifified token protecting the signing key and what is the evaluated integrity of that token, what kind of terminal and merchant is used for the digital signing environment, the physical location of the signing, past consumer transaction history, past terminal transaction history, etc. one might imagine financial institution having different minimum token and key length requirements for different kinds of accounts and/or different kinds of transactions (based on factors like overall risk and the relative security strength in which such tokens and signing keys operate). you might some authorities setting the requirements don't understand the overall risk and infrastructure issues ... they can always go for the maximum available for everything ... even if some of the specified requirements don't make any sense in a particular overall infrastructurt. the other may be that the infrastructure has no means of differentiating and authorizing at different levels of risk ... so that the requirements have to mandate the maximum strength for all components, always assuming the worst case risk. there may be a lot higher risk with a (digital signature) singing public key gets confused with human signatures ... which then may carry with it the implicattion of a human read, understood, agrees, approves, and/or autherirzes the contents of what is signed, the risk exposure might also be greater is if the overall infrastructure is an offline environment that is totally dependent on digital certificates and PKI operation as opposed to a real-time, online environment that can take into account a lot larger numgber of factors (including aggregation of past transactions). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
