From: Bill Stewart <bill.stewart@pobox.com>
Date: Sat, 13 Dec 1997 11:20:55 +0800
To: Rick Smith <cryptography@c2.net
Subject: Kong Re: Please Beta test my communications cryptography product.
In-Reply-To: <199712050100.RAA04735@proxy4.ba.best.com>
Message-ID: <3.0.3.32.19971212190603.0076b324@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



>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