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.

> http://www.jim.com/jamesd/Kong/Kong.htm

> 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.

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

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