- cypherpunks-legacy - lists.cpunks.org

Steve Kent on certification trust paths
by gnu 26 Nov '92

26 Nov '92

Steve is one of the key folks in the Internet PEM project. He sent this message last month during a discussion of why PEM uses top-down key certification rather than the "mesh" style that PGP uses. I hope that our (cypherpunks) experience with mesh key exchange will teach us a lot about whether and how it works. Nobody has ever tried this before, so we are doing research! John Gilmore ------- Forwarded Message Message-Id: <9210212125.AA27956(a)TIS.COM> To: Peter Williams <P.Williams(a)cs.ucl.ac.uk> Cc: pem-dev(a)TIS.COM Subject: Re: Perhaps OSI security is not possible in a liberal community! Date: Wed, 21 Oct 92 17:24:42 -0400 From: Steve Kent <kent(a)BBN.COM> Peter, You have receibved replies from a couple of folks (via pem-dev) who have expressed views on why a strictly hierarchic certification system is not required. As the author of the words you cited in raising your question, and as an advocate of a strict certification hierarchy, let me respond. It is clear that one can construct a certification system which is not a tree, but rather is a mesh. The PGP approach is an example of such a scheme and X.509 permits this. However, there are a number of advantages to a hierarchy which have motivated its use in the Internet: In a pure certification mesh, one acquires certification paths by following chins of implied trust. It is not at all obvious that this approach scales well. The PGP folks do not yet have significant experience in this regard, so it will be interesting to see how the mesh develops over time. Most folks who have spent considerable time exploring this issue believe that unbounded transitive certification, with no required name relationships, is a bad idea. The rationale is that whatever trust one might accord to an entity may not apply transitively. I may give a house key to my neighbor to be able to open my house under certain circumstances, but that does not suggest that I would give the key to whomever that neighbor provides his key. It seems difficult to characterize the nature of trust in these "lateral" arrangements and applying trust transitively is even more difficult. From a user interface standpoint, it is generally agreed that most users are not capable of evaluating a certification path. In PEM we feel that a user should know the distinguished name (or an alias assigned by the user locally) of a message originator/recipient, and some indication of the policy under which the user was certified, e.g., a short-hand name for the PCA. This is about all we expect a user to be able to deal with. The though of a user really paying attention to (much less applying meaningful value judgements to) all of the DNs in a certification path boggles the mind. I won't clain to understand all the details of what PGP provides for managing key rings. However, if one were to provide a management tool for mesh certification in general, I think it ought to permit a user to construct a trust graph expressing the relationships implied by certification paths he acquires. The user might be able to express a degree of trust and a level of allowed transitive certification for each entity in the graph. Disply of this info, to allow a user to manage the graph, would be necessary. All in all, it seems to be pretty complex and it is highly questionable if most (many?) users could make use of this facility without getting confused. But, this analysis is based on reasoned speculation, not actual experience. The naming issues is a related, but somewhat indepedent topic. DNs provide many good features for use with a certification system. One wants the names to be globally unique and manageable in a distributed fashion. Being able to express a through, rich name is important if this technology is ever to expand beyond casual use in R&D environments. Note that DNS names are not great choices. Although there are close to a million DNS host names, that represents a very small portion of the population that one wants to serve with a system like PEM. Most DNS names are very short and will eventually reuslt in collisions as more individual and organizations are registered. The problem is worst in the U.S. where we have adopted a parochial scheme with GOV, EDU, COM, ORG, and MIL at the top, vs. other countries which prefix their DNS names with a country code. What's worse is that many DNS indivdiual names are not very mnemonic and thus don't offer much in the way of indentification outside of a very narrow context. There is sometimes confusion about the role of certificates. X.509 makes it clear that they serve only for identification, not authorization. This is improtant because it is difficult enough to manage them for identification purposes without overloading authorization info on them. Also, the entities who grant authorization may often be different from those who vouch for the identity of an individual (or organization) and thus this independent is appropriate. Often there seems to be a desire to bind more info into a certificate in support of authorization, but I (and many others) believe this to be a mistake. One can construct other certificates (like the PACs EMCA has defined) to use public key technology for authorization, leveraging off of certificates used for identification. Finally, there is revocation. We have adopted both a push and a pull facility for CRLs in PEM and the PEM CRL format differs slightly from that in X.509. Many folks fail to appreciate the subtleties of CRLs at first. Hot listing on a CRL says that either a key has been compromised OR a name has changed. If we have fine-grained, organizationally-related names, then these names will change with some frequency and thus CRL entries will arise. Because a certificate establishes a binding between a name and a key, it seems appropriate that only the entity which vouches for this binding (a CA of some tyep) should be able to revoke it. That is the model we use in PEM and we add the important feature of having each CA advertise when it will issue its next CRL, so that user's know when each CRL they hold is obsolete. Peter, I hope this note helps explain the very terse words I put in the PEM key management document. Steve ------- End of Forwarded Message

1 0

neat features that could be added to the crypto dongle
by yanek＠novavax.nova.edu 26 Nov '92

26 Nov '92

Here are some neat ideas: If you and me both had one of these devices, we could connect them, and exchange our public keys. We could also exchange other public keys on our keyrings. Another useful thing it could do: watch the incoming rs-232 traffic for anything that looks like a public key. When one is detected, you would have the option of storing it on your keyring. It could have an LCD display, and then it could calculate a hash function of someone's public key and display it. This would make it easy to verify keys by phone or any other means. Instead of spelling out the 130-character alphanumeric sequence you would only need to verify a short (maybe about 8 to 12 digits) number. As someone mentioned, if something has a keypad and an LCD display, it can also be a calculator. And, if it has two RS-232 ports it could be a break-out box or a line analyzer. But I think this is creeping featurism. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

1 0

RE: PGP on local machine (was Re: MacPGP)
by DrZaphod 26 Nov '92

26 Nov '92

In Message Wed, 25 Nov 92 10:30:09 PST, Eli Brandt <jarthur.Claremont.EDU!ebrandt(a)netcomsv.netcom.com> writes: >You compose the message, using emacs or some other Turing-complete editor. >You hit the "PGPify" key [sequence]. >emacs echoes a special START string >The local comm program recognizes it and goes into "capture" mode. >emacs blats the plaintext to stdout, where it is captured. >emacs echoes a STOP string. >The comm program sees this, stops capturing, shells to DOS, and runs PGP. >emacs kills the original text block. >(emacs command ends) >The comm program shoves the cyphertext into the uploadt editor to write your messages then you've just lost the whole reason for encryption. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod(a)ncselxsi.uucp] Technicolorized

2 1

advantages of RS-232 based crypto device
by yanek＠novavax.nova.edu 26 Nov '92

26 Nov '92

A number of people responded, both privately and publicly to my RS-232 dongle idea. Several offered help with the hardware/schematics design. Some thought that PCMCIA cards would be better for this. Theoretically, yes. They could contain more memory and processing power in a smaller space. There are several problems with PCMCIA. First, not nearly as many devices have PCMCIA interface as RS232. Second, you can not make a PCMCIA card yourself, nor can you easily open it and look what's inside. My proposed design would consist of only off-the-shelf parts, the schematic would be published, so anybody could build the device for himself. I might distribute it in the kit form, which would include all the parts and the PCboard, and a case. This way, you can test each component in any way you want, and then put the thing together by yourself. Even if you got the complete unit from me, you could open it up, and look inside. You could see if it actually corresponds to the schematic. Some people doubted the possibility of its second greatest advantage, the ability to work with any computer or terminal regardless of operating system, mail software, comm software, etc. Also it could be used between an ASCII terminal and a (non-trusted) host. Here is an example of a design that I think will work with any software/host/terminal/etc combination. If I am wrong, please let me know. NOTE: this is not the final design of the device, just an example. ===================================================================== Since the device needs to have a processor anyway, it may as well have a built-in simple line-mode editor that is good enough for composing mail messages. So to use the device to send mail, you would: 1. Give the mail command to your host (or BBS) using whatever command or menu selection you normally use to send mail. Then if the mail program puts you into a mode-based editor like vi, enter insert mode (press i or a). 2. Push the "encrypt" button on the device (or send a magic sequence from your terminal). 3. Type your message in a simple BBS style (in case you have not used a BBS, this is the kind of editor they usually use: You simply type text. Every line has a number. When you press return, the next line number appears. At the beginning of a line, you can issue commands for example with a slash or a dot. commands include things like DONE, ABORT, DEL LINE, INSERT, etc.) If you had the text prepared on the local machine, you could simply transfer the text, and then type the "DONE" command. All this while, the text is only stored in the memory of the crypto device, the remote host is still waiting for input. So plaintext never crosses the line or network. 4. When you are done, the text would be encrypted (you would select a public key from the keyring, or it could be automatically determined from preceding text (such as the e-mail address). You would have the option of signing the text. The device transfers the encrypted text to the host and becomes transparent. You then type the command to tell the host that you are finished typing the message, and off it goes! ========================================================================== Now, if you see any reason why the above would not work, please let me know. A number of people wondered if the tamper-proof memory for private key storage was necessary. Some other people wondered if it was in any way effective (i.e. if someone gets the device, they can just use it to decrypt/sign stuff; so what if they don't get they actual key out of it). I tend to agree. I will have to think some more about this. It would certainly make the design much simpler (and cheaper, and consistent with the desire for off-the-shelf parts) if I avoid use of such exotic hardware. The private key may be protected from use by un-authorized users by encrypting it with a key, and requiring it to be entered on a keypad on the device. Someone suggested that the key must be typed in periodically (every x minutes). The only case I could see a problems with this approach is if "they" get you while you are using the device. For the next x minutes they can decrypt any old messages they may have stored. I believe this addresses all the concerns that have been voiced about this device. If you have any other concerns, questions, or comments, please let me know. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek(a)novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819

1 0

Re: RS232 Crypto Dongle (idea for widely accessible crypto technology)
by karn＠qualcomm.com 26 Nov '92

26 Nov '92

>Much better for this application is the PCMCIA standard, which has >plenty of room for circuitry. I had this in mind too. But there's a problem -- if we have to depend on commercial manufacturers to build these things, how will we know if we can really trust them? I'm not impugning the manufacturers themselves, as it's entirely possible that the FBI and/or NSA wouldn't even let them build and sell a device like this if it's "too" secure. That's the paradox of freely-available crypto software like PGP. The software, including source, is open for inspection by all. But because it runs on general purpose computer hardware, it's vulnerable to all of the usual computer security attacks (viruses, modifications to secretly record or transmit keys, keystroke monitors, etc). Going to small, dedicated pieces of hardware removes these vulnerabilities, but then we're right back where we started -- with an opaque piece of commercial hardware whose secure operation we can't verify. Unless, of course, we can get the technology to build PCMCIA cards ourselves out of readily available parts... Phil

3 2

News item
by bwebster＠pages.com 26 Nov '92

26 Nov '92

Is this sudden flood of cypherpunk mail this afternoon mean we're all avoiding doing any work before taking off for Thanksgiving? ;-) AP news item in today's San Diego Union: Headline: "CIA chief hints change needed in ban on probing Americans" Excerpts: WASHINGTON--CIA Director Robert Gates says changes might be needed in the U.S. law that forbids the agency from collecting information about Americans or U.S. companies. Such changes might enable the CIA to better support the Justice Department and other law enforcement agencies, he said in an interview with the Associated Press. The idea grew out of a recent storm of accusations by Democrats in Congress, Justice Department officials and a federal judge that the CIA withheld information in the case of $5.5 billion lending scheme to Iraq by an Atlanta bank. ... [Gates said] the case of the Iraqi loans raises a broader issue of what the CIA is expected to do to aid law enforcement in such fields as financial crimes. Under current law, the CIA is strictly forbidden to collect information on Americans or American companies. "At some point it seems to me, very early on, we and Justice...and the Congress are going to have to...have some sort of serious discussion about whether there are changes in the law that are needed that will clarify some of the ambiguities and what we can and cannot do in support to law enforcement," Gates said. He did not elaborate. ... ----------------

1 0

Re: The Cypherpunks Mail Project
by tony＠morgan.demon.co.uk 26 Nov '92

26 Nov '92

In message <9211251705.AA17774(a)soda.berkeley.edu> you write: > > It is also my suspicion that simple PGP decryption support is fairly > straightforward, being mostly the ability to run a command on a block > and replace the block with the output of the pipe. I'd like to chip in here, in my _very_ newbie way, that not everybody is running a unix system with the ability to pipe things between processes in so facile a manner. I access the net through a dial up from a MS-Dos machine running KA9Q software. My PGP is of the stand alone sort. I cannot easily get a new mailer to run on this system. Whatever protocol is decided upon, it would be useful if it were not too host-system specific. [FX Crawls back under stone] Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony(a)morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny(a)cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301(a)compuserve.com| +=================+===============================+==========================+

2 1

Re: RS232 Crypto Dongle (idea for widely accessible crypto technology)
by karn＠qualcomm.com 26 Nov '92

26 Nov '92

I've also been thinking about the risks of running crypto software on hackable PCs and ways of protecting against this with external special purpose devices. My thinking is to limit the external "dongle" to the one function that is truly sensitive and worthy of special protection: RSA secret key operations. It seems to me that whenever you use a PC to encrypt or decrypt something, you have to accept the risk that it might have been hacked, and whatever you do on it might be secretly recorded. But when I now run PGP (or any similar package) on a machine, I must risk much more than this every single time I type in my pass phrase, namely *everything* that ever was or will ever be encrypted with this same RSA key pair. This may well be an unacceptable risk, especially if I'm temporarily borrowing somebody else's machine or using one in a public area. I see this as THE major obstacle to our goal of routinely encrypting all communications, sensitive or otherwise, as a way of "desensitizing" the world to the use of cryptography. The way around this risk is to move the RSA secret key storage and processing operations to some external dongle. The device would have only one primary function -- the execution of an RSA secret key operation. It would not allow the secret key to be read out of the device, although it might have a "zeroize" function to destroy it. (It might also include a good random number generator for the convenience of the host computer.) Everything else (data compression and armoring, public key operations, symmetric cryptography, etc) can and should go in the PC where cycles and memory space are much more plentiful. If the dongle has a built-in keypad, then it could store your RSA secret key encrypted with a PIN that you'd have to enter to enable the device. This would protect you if the device were stolen. Of course, the best protection is to make the device so small that you can conveniently keep it with you at all times instead of having to store it someplace. I believe that "smart cards" are already available on the market that do these or similar functions, although they are much more widespread in Europe than in the US. Comments? Phil

2 1

Unlabelled PGP messages
by ghsvax!hal＠uunet.UU.NET 26 Nov '92

26 Nov '92

Peter Shipley points out that PGP messages are labelled with an identifier of the person they are sent to. This hurts the anonymity of the messages somewhat. What PGP actually puts in the cleartext message header is the "Key ID" of the recipient. This is the low-order 64 bits of the RSA modulus "n" of his key. (PGP displays only the low-order 24 bits when it shows key ID's, but it keeps 64 bits internally.) I understand that there was some discussion during the development of PGP 2.0 of having a mode where this wouldn't be done. One possibility would be to output a key ID of all zeros for a message which wanted to hide who it was for. Then, as Peter suggests, it would either be trial-decrypted by all of the secret keys you have, or, more simply, it would just try your "default" secret key. Most people only have one secret key so both methods would be the same in most cases. Doing it the second way would be a pretty easy patch to PGP. I'm not so sure now that this feature is that helpful. First, you don't have to put your real name in the "user name" field. You could use a pseudonym. So you really don't have to give much information away about yourself the way it is now. Also, if someone is sending a message to you using encrypting remailers, they would encrypt it using your key, add remailing instructions for the last remailer in the chain, encrypt that using that remailer's keys, add remailing instructions for the next-to-last remailer, encrypt it again, and so on. (This would be done automatically by some future software - you wouldn't want to do this by hand!) The result is that the mail you send does not expose the key ID of your recipient. That information is only revealed when it comes out of the last remailer in the chain. And by that time, it's no secret, since that last remailer is using the true email address of the recipient anyway. So it's not giving anything away. For the other kind of anonymous messaging, where you just post to a newsgroup or use some other kind of "broadcast" system, the key ID is revealed and for this case it might be better to hide it. But, the key ID can be useful in this application by letting you know which messages you should decrypt. No one has to know that a particular key ID is "you". You can still download 1000 messages and only read yours without anyone knowing which ones you read. But with key ID hidden you would have to decrypt them all to see which are yours. Do you want to decrypt all 1000? This will take minutes, hours, or days, depending on your key size and computer speed. (Most of the decrypt time is spent doing the RSA step, at least for most messages, and you can't tell if it's for you without doing that step.) This still might be a good idea, but I'm not sure... Hal Finney 74076.1041(a)compuserve.com

1 0

Re: Electronic Banking
by mark＠coombs.anu.edu.au 26 Nov '92

26 Nov '92

>(A minor note: I ended up doing the Xeroxing for free, which hasn't >yet been declared illegal...though I presume you'll all carefully note >this on your tax returns, as such "barter exchanges" are reportable >income. In theory, which shows how hopeless tax collection is >becoming, all of our "mutual consulting" on this list, and on the Net >in general, is _taxable income_--just as if we were plumbers and carpenters >getting together to work on each other's houses. A crazy system.) So *thats* why nnacct is there :)... Does the tax office get an email from each news admin every fiscal year? :) So they can charge us for services rendered by the net? With regard to digital cash, I have yet to read (or have forgotten the definition) the implementation. What I preceive it as is a form of IOU's that if someone does something for you then you send them an applicable amount of credits. To simplify it a bank could issue credits and people could trade in them, sending them back and forth, each digitally encrypted and based on the amount of credits in each persons bank account. I assume each transaction would be validated through a bank to ensure the credit is unique and the right value? E.g: Customer gets suppliers account number from the supplier encrypted with the banks public key. They send it and the amount of cash to transfer to the bank all encrypted with the public key of the bank. The bank decrypts, gets the amount and decrypts the destination account. It then sends a message to the supplier saying that amount has been deposited in their account and the transaction between the customer and supplier can be completed. Otherwise it tells the supplier (and customer) there is a problem with insufficient funds or incorrect data. The cash may be held in ether until both parties confirm the transaction has been completed. If the commodity is electronic data the supplier may send to the bank a transaction private key encrypted with the customers public key so that the customer cant cheat the supplier as he has to ask the bank for the information to access his/her data which has been encrypted with the other half of the transaction keypair. That way the bank knows the transaction has been completed and it finishes the transfer of funds and sends the transaction private key to the customer. Each commodity, especially if it was physical might be serialized so there could be proof that the customer purchased that item with that SN. If the merchant was a crook the audit trail would catch him... the customer wouldnt be able to cheat as the merchant wouldnt have to release the goods (as is the situation now in Real Life (tm)) until the funds were paid. Issues of Big Brother spying on your transactions apply here but I guess one could always use a psuedonym for the electronic commodities and a postal box paid for with digital anonymous cash for the physical stuff.. (assuming it was mail order... you wont have to give a name for store buying, just a bank public key and your encrypted account number.) Someone might even want to set up a physical forwarding company which merely acts as a buffer for people to increase their privacy. Paid for anonymously and digitally. I havent heard of any companies specialising in this type of service to date. This make any sense? Has it been said before? Mark mark(a)coombs.anu.edu.au

1 0