Please Beta test my communications cryptography product.
-- I have produced a program that, like PGP, provides digital signatures and communications encryption. http://www.jim.com/jamesd/Kong/Kong.htm This is the first beta. Please beta test this product. The important difference between it and other products that provide digital signatures and encryption is that it is not certificate based. Instead it is signature based. This eliminates the steep initial learning and management curves of existing products. The user does not need use and manage specialized certificates except for specialized purposes The big complexity and user hostility in existing products is creating and managing certificates. Perhaps more importantly, it also eliminates the threat we saw in England, the threat of the government giving itself a monopoly in certificate distribution, potentially creating the Number-Of-The-Beast system, where you need a government certificate to log on to dirty picture sites, to buy, to sell, to put up web pages. The key feature of the proposed product is that any digitally signed document can be stored in the database, and itself performs the functions of a certificate, just as a normal handwritten signature does. The user usually does not need to check a document against a certificate to see if it was signed by the "real" John Doe. Instead he normally checks one document against another to see if they were both signed by the same John Doe. And similarly when he encrypts a document, he does not need to use a certificate to encrypt a message to the one real John Doe, he merely encrypts a message to the same John Doe who signed the letter he is replying to. At present people have to deal with certificate management problems regardless of whether they really need certificates. For example the most common usage of PGP is to check that two signatures that purport to be by the same person are in fact by the same person. Unfortunately you cannot check one signature against another directly using PGP or any of the other existing products. Instead you have to check both signatures against a public key certificate, even if the authentication information in that certificate is irrelevant to your purpose, which it usually is, which means that you have to download the certificate from somewhere, and the person signing it had to upload it somewhere. As PGP always checks a document against the certificate, rather than against any other document the user happens to feel is relevant to the question, the person signing the document needs to get his certificate properly signed by some widely trusted third party, which is too much trouble or too complicated for many people. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG z8/j/L3kF7oCmOp/iF2oh/pwgP/mATjOTUdv1uGy DlPh9Op11Z1CtFuByebVsk8yJo4WuUMuFk4S/TMp --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we are. True law derives from this right, not from the arbitrary power of the state. http://www.jim.com/jamesd/
James A Donald <jamesd@echeque.com> writes:
-- I have produced a program that, like PGP, provides digital signatures and communications encryption.
This is the first beta. Please beta test this product.
_________________________________________________________________ System requirements Kong will only run under Windows 95 and Windows NT or later. Does the `or later' mean modern, safe software (like Linux), or what?
At 5:00 PM -0800 12/4/97, James A. Donald wrote:
-- I have produced a program that, like PGP, provides digital signatures and communications encryption. http://www.jim.com/jamesd/Kong/Kong.htm This is the first beta. Please beta test this product.
Actually, it's more fun to beta test the product concept than it is the product itself, especially since I don't use Windoze these days. First of all, the product Kong is not solving the same problem PGP was designed to solve: PGP follows the classic approach to e-mail encryption, with certificates to address MIM and personal authentication issues. Kong only concerns itself with individuals' cyberspace identity. But there's something appealing to this simplifying notion, and I'm interested in anything that makes crypto easier for people to understand and use. I admit I can't figure out what crypto mechanism Kong is really using since there's obfuscating talk of passphrases and secrets. But I can see how I'd do it with conventional public key mechanisms. The 123 byte (or whatever) string included in the message would incorporate a digital signature over the message plus the public key used to produce the signature. Thus, each message contains an internal integrity check. Recipients also would be able to compare the public keys used to sign two or more messages allegedly from the same recipient and verify that they were signed by the same entity. (technical nit: I'd prefer to put the PK in a special message header field and only stick the digital signature data in the message body, like PGP). Since Kong does not use certificates, it is vulnerable to the Man in the Middle (MIM) attack and indeed to forgery. However, I also suspect that the behavior of a long lived cyberspace identity would make a MIM attack detectable and/or impractical in the long run. If John Doe consistently includes a public key in his web site, messages, and postings, then recipients have a relatively independent way to validate the key being used in a message allegedly from him. The public key is literally associated with the cyberspace identity and its "reputation capital." Since no third party is attesting to the identity, you could argue that it's exclusively established by the holder's cyberspace reputation. This is an interesting property. Key revocation remains a problem, as with any PK system. The key holder essentially starts over associating reputation capital with the new key. This could be weird (but the topic of an interesting tale) if the revoked key was actually disclosed to an adversary and actively used in forgeries. As mentioned above, I haven't used the produt itself. But the underlying concept may represent a practical subset of classic e-mail security. Rick. smith@securecomputing.com Secure Computing Corporation "Internet Cryptography" at http://www.visi.com/crypto/ and bookstores
Rick Smith <smith@securecomputing.com> writes:
I admit I can't figure out what crypto mechanism Kong is really using since there's obfuscating talk of passphrases and secrets.
What James describes on the page is that he is storing the private EC key in a file. The file is optionally encrypted with a passphrase. He also describes how the key file can be stored on floppy. The term he uses for the private key file is "secrets file". This much is fairly standard. The novel feature is that he includes the PK with the signature. I consider this useful, in that if you ever receive a communication, or read a post you wish to reply to you have all the information required to reply without going to a keyserver. You are vulnerable to MITM, but including a reasonable subset of the WoT with a post is not an option due to size. Another interesting option with EC is to derive the key from the passphrase, then there is no private key file.
Since Kong does not use certificates, it is vulnerable to the Man in the Middle (MIM) attack and indeed to forgery.
Most uses of PGP are subject to the same attack, because people do not have enough web of trust connectivity. PGP certificates give you the tools to avoid MITM attacks when you knew someone before hand. A widely deployed WoT generally makes MITM harder even when you converse with people only electronically, because somebody knows them in person, and this may be reflected in the WoT. The fact that it is easy to fabricate a whole community of fictitious people who know each other is interesting also. One method you could use to restrict this somewhat is to add a cost function to creating identities. A certificate proving certain monies have been paid for the identity, or a hash collision over a certain size.
However, I also suspect that the behavior of a long lived cyberspace identity would make a MIM attack detectable and/or impractical in the long run. If John Doe consistently includes a public key in his web site, messages, and postings, then recipients have a relatively independent way to validate the key being used in a message allegedly from him.
This is similar to including fingerprints at the bottom of posts. In some senses John Doe's web site, messages and postings define who he is in cyberspace.
As mentioned above, I haven't used the produt itself. But the underlying concept may represent a practical subset of classic e-mail security.
I strongly suspect it entails a high percentage of the use of PGP. Very few people have WoT connections. And there is the question of what a WoT link means. The only people I have direct WoT links to are people who I first met electronically. I wouldn't know them from Adam. How do I know the person I met is the real Ian Goldberg, or whoever. Also an inherent problem is that just because I met Ian Goldberg once does not mean that all the people he signs keys of are who he thinks they are. The problem of preventing MITM can be viewed as the task of making the MITM's job difficult, and making it difficult for the MITM to perform many MITMs at once. One way to go about this is to distribute your belief of other peoples keys. The potentially helps to strengthen the WoT because you may work your way around the MITM by a link he does not control. For example you could download the list of email addresses from a keyserver and spam them all with the set of fingerprints of all the public key ring that you use (or all of the keys on the keyserver). Not that they would thank you for it, spamwise, but if there are in existance any MITM's it could conceivably flush some out. Another lower bandwidth method of making the MITM's job harder is to sign and/or publish hashes of public key databases -- download the keys, or some useful easily definable subset of keys on keyservers, and publish the hash of them in as many media as possible (web, finger, news, mail, newspapers, etc.) For example if the operator of a public key database published a hash of all the keys in his database in a widely available newspaper, the MITM now has to make sure that John Doe doesn't see this newspaper, or that the newspaper John sees has been reprinted espescially for him. If John Doe is suspicious he will stop a random person in the street and ask to see the key hash section breifly. In general John Doe's strategy to avoid being the subject of a MITM attack should be to be unpredictable in the channels he uses for authentication and communication. Let's say John buys a book on cryptography, and the author included his fingerprint. Then John could use this person to authenticate a key with Alice. He could write to the author, including a nonce with the plaintext, and ask the author to check that the key he thought belonged to Alice really did belong to her. Interlock protocols are another method of complicating the MITM's task. If Joe develops the habit of posting the hash of messages he is about to post a day in advance, the MITM must think of something to say also, and publish the hash, so that it can publish something a day later. As the MITM's messages now don't match with what Joe said, the MITM has to lie some more to keep up the game. We would like to overload the MITM so that his task of lying becomes computationally infeasible. Adam
At 12:06 AM +0000 12/6/97, Adam Back wrote:>
Another lower bandwidth method of making the MITM's job harder is to sign and/or publish hashes of public key databases -- download the keys, or some useful easily definable subset of keys on keyservers, and publish the hash of them in as many media as possible (web, finger, news, mail, newspapers, etc.)
I have always felt this to be a nearly complete and practical answer to MITM attacks. Frozen versions of major key databases would be made available on the net along with a master list of hashes. The hash of that master list would be widely distributed by electronic and non-electronic means. One would only have to do it periodically, say every year or two. Why can't this be done now? A public billboards would be a good location to post the master hash. (I like to call the whole approach the "Billboard defense.") I suspect one could rent visible space on the back side of billboards quite cheaply. Another good location would be on a bulletin board near a publicly accessible library. The MIT "infinite corridor" comes to mind. A variant is for PGP users to post their own fingerprint near their house or place of business. A business-card-size sign in a window near the front door would do. People who agree to post such signs would be identified in the key server database. A suspicions John could then look up a suitable public key holder in their area, visit their house, and verify the fingerprint. John would then e-mail an encrypted request to verify a suspect key to that person.
Let's say John buys a book on cryptography, and the author included his fingerprint. Then John could use this person to authenticate a key with Alice. He could write to the author, including a nonce with the plaintext, and ask the author to check that the key he thought belonged to Alice really did belong to her.
My PGP fingerprint is printed on page 232 of E-mail for Dummies, 2nd edition, IDG Books Worldwide, which I co-authored. Arnold Reinhold
At 5:00 PM -0800 12/4/97, James A. Donald wrote:
I have produced a program that, like PGP, provides digital signatures and communications encryption. http://www.jim.com/jamesd/Kong/Kong.htm This is the first beta. Please beta test this product.
The web page says that the first beta had some problems, but there are some good files in its directory, in particular an explanation of elliptic curves cryptography that avoids most of the math. The code that's there appears to be visual basic or something similarly unreadable. Kong is deliberately far simpler than PGP; it looks like it's limited to the following: - Signed Message: Delimiter, Message Body, ECC Public Key, ECC Sig. I didn't notice what hash was used for the signatures -- SHA? - Encrypted Message: ECC(SessionKey), RC4(Message Body, SessionKey). I'm not sure if there are headers that include the recipient's key, or if there's any special form for an encrypted-and-signed message. I assume there's no multiple-recipient form? - there's also symmetric-encrypted form. - Decrypt Message - Compare signatures from two messages It turns out you can replicate many of the functions of PGP using this set of tools. And ECC keys are nice and short, so there's less need for keyservers and such. - Instead of a keyring, keep a directory of signed messages from people - To send someone your key, send them a signed message, preferable one that will mean something that tells them it's you. - To verify a signature on a new message, compare the signature with one on your key message. - To "sign" someone's key, take a message from them, add some introductory message of your own, and then sign it: -- Alice gave me this message at the Cypherpunks Against Nukes rally. I've known her for a couple of years, and I doubt she's a narc. Remember to remove the >s before checking it. > -- > Hi! I'm Alice Liddell, from the Vegetable Legalization Front! > You can catch my show on VLF Radio on Thursday nights, > or send email to askme@juno.com. > -- digsig Alice > 239084509834098f9a8900cb989989909890 > 2jcxjsdopicjospijfijvoisdjfvoisdjfvoijfdsvoij > i09809cv8qf234u0r9duw90cfdwre90f8cw8c900w8f900 -- Digsig Bob Dobbs <sales@subgenius.com> 230deadbeef809890slackslackslack0y97 090hlkh345345kjhlk34h5jh5lk34h5kl3h5 jh5lkj34h543kjh5kj34h5k3l4j5lj3k4h5h Some technical notes about format: 1) Are the Signer's Name and the ECC key included in the material that's hashed for signature? Doing that is valuable, but depending on it makes it more difficult if people change addresses. 2) It would be nice if the starting and ending delimiters were different. This would let you nest messages without needing >s. Can Kong tell a nested opening -- from a closing --digsig ? Are --s escaped, or at least <NL>--digsig? 3) How are newlines and whitespace in the message body handled for signatures? Canonicalized? Ignored? Not worried about? This affects not only reliability of signatures after emailing, but also affects signing binary files. 4) I'd guess, since you're using 240-bit ECC and base-64 encoding, that the first 40 characters of garble in the signature are the key, and the remaining 80 characters are the signature itself? If so, is there some easy way to use the 40-char string, e.g. type in a copy from the bottom of a business card? Or are signed messages the only way to do verification? On the other hand, it's rather pleasant that the normal way to distribute keys proves that the sender possesses the key. Some of the documentation says something about the key being derived from your passphrase and a randomness file hashed together. How does this affect multiple keys generated by the same user? I assume it means you can't share passphrases between keys. 5) Is the format of the signature freeform, or do the newlines and whitespace have to be in their official locations? If the latter, what flavor of newline do you use? CRLF? LF? CR? LFCR?
Key revocation remains a problem, as with any PK system. The key holder essentially starts over associating reputation capital with the new key.
Since signed freeform ascii messages from other people can be key certs, you're not limited to rebuilding reputation capital from scratch. On the other hand, since certs aren't an automated process, revocation is tougher than usual to automate as well. There are three usual reasons for revocation: 1) You've lost all copies of your key (disk crashed, no backups, or you just forgot your passphrase.) So keep backups. The keys are short enough that it would be nice if you could type in your secret key from paper, but that may depend on the randomness file implementation. And you can get notes from your friends stating that you're the same person they vouched for before. 2) Someone else found one of your key backup copies. It's easy to send out mail signed by your old key saying "Someone stole my old key. Don't trust it! Here's my new key". The hard parts are getting people not to trust new messages signed by your old key, since key handling isn't automated, and getting them to trust the new key you're handing out (since it could be the key-thief sending out the new key.) Signatures by your friends on your new key can help. 3) Expiring keys every so often to reduce the risk of 2). Assuming the name format in signatures is freeform, you can indicate key expiration in the signature line... Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
participants (6)
-
Adam Back -
Arnold G. Reinhold -
Bill Stewart -
James A. Donald -
nobody＠REPLAY.COM -
Rick Smith