llo...@gmail.com (Lou Losee) writes: > Yes you are correct that you have to initiate your trust somewhere. The > paradigm is that you trust the vendor that delivers the CA certificates to > you (e.g., Mozilla, Microsoft, IBM, etc.) > Hand delivering keys defeats the purpose of using certificates. If you > were going to hand deliver keys, you might as well just use a symmetric > cipher rather than asymmetric. If you want perfect unbreakable encryption > then you should hand deliver one time pads between the parties.
re: http://www.garlic.com/~lynn/2018c.html#28 Software Delivery on Tape to Be Discontinued symmetric key ... like passwords ... are shared secrets ... you need a unique value for every security domain (or use, as countermeasure to cross domain attacks). the same single public/private key pair could be used for every security domain in lieu of unique shared secret ... shifting from an institutional centric security paradigm to a person centric security paradigm. this is somewhat analogous to biometric authentication ... but can work at a distance rather than requiring person's biometric be physically present. the trivial approach is registering a public key in lieu of a unique pin/password at every institution ... we actually did example implementations for radius, kerberos and some number of other widely used authentication infrastructure. problem was that it would generate no new revenue stream ... and the ceritication authority industry really wanted their $20B/year tirivia ... in the digital signature scenario ... some hash (SHA, MD5, etc) is calculated for the data, the hash encrypted with the private key and appended to the data. the recipient decrypts the digital signature with the public key and compares the decruypted value with recalculated hash. This confirms/authenticates that the original data hasn't been changes and also confirms/authenticates the sender. The use in lieu of pin/password ... the institution has to protect against replay attacks. Rather than the user generating the data that is signed ... the institution sends the user some unique data. The user than encrypts the hash of the unique data with their private key and returns the encrypted hash to the institution (doesn't have to return the data, since the institution already has it). The institution then decrypts the returned value with the public key (saved in file that had previously stored pin/password) and compares it with the hash of the originally transmitted value. There is no longer a danger of pin/passwords being skimmed or the pin/password file being copied ... and in fact can be transmitted completely in the clear (w/o any additional encryption). We used this for the X9.59. Financial industry started out saying that they could not trust some other certification authority and would only recognize "relying party only certificates" (i.e. only recognize certificates that they had issues). However, a certification authority has to create a business process that does background on the public key and then save the public key in some administration file (before issuing a certificate). However, for a financial institution, that would all be collapsed in account record. But in any sort of financial authentication, it involves accessing the account record ... where the public key has been stored ... having it also in appended digital certificate (that is typically 100 times larger than financial transaction) is then redundant and superfluous (since a financial institution will already have the public key). Then for the whole financial industry, certificates became unnecessary. Also since X9.59 account transactions could only be done with public key (digital signature) ... crooks were no longer able to do fraudulent transaction against an x9.59 w/o the corresponding private key. Since the private key was never divulged ... it was no longer necessary to hide/encrypt/ssl/tls such financial transactions (skimming, breaches, evesdropping, wern't prevented, but the risk of crooks being able to use the information was eliminated). One of the things that the transit industry then asked was if I could design a chip that could do such transactions and be implemented in a contractless transit card (i.e. amount of power for doing calculations is severely limited) and time constraint of turnstyle (1/10 sec or less). Turns out using a variation of ECC would be as strong or stronger than RSA ... and do the calculations within the power and time constraints of a transit contactless turnstyle. other trivia: its certification authority ... not certificate authority ... the service provided is certification (some correspondance between the public key and some entity) ... which is then encapsulated in a certificate. However, since fine print frequently says that the certification has no warrenty ... there is frequent disire to distract the market ... and make believe that the certificate by itself has some magic pixie dust property. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
