From: jamesd@echeque.com (James A. Donald)
Date: Sun, 14 Dec 1997 04:35:56 +0800
To: Bill Stewart <cryptography@c2.net
Subject: Re: Kong Re: Please Beta test my communications cryptography  product.
Message-ID: <199712132023.MAA06952@proxy4.ba.best.com>
MIME-Version: 1.0
Content-Type: text/plain



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

At 07:06 PM 12/12/97 -0800, Bill Stewart wrote:
> The web page says that the first beta had some problems, 

Beta 2 is now out.

Please uninstall your old copy, using "Add/Remove programs" in the
control panel, before installing the new copy, as overinstall does not
work.

(If you forgetfully overinstall, a warning comes up, but most people
cheerfully disregard the warning)

>- Signed Message: Delimiter, Message Body, ECC Public Key, ECC Sig.
>	I didn't notice what hash was used for the signatures -- SHA?
>	

SHA:  I failed to document that, will add it to the documentation.

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

Multiple recipient form works, but the user interface to use it does 
not yet exist which makes it kind of useless.  Coming soon.

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

Yes:  However the name is only hashed in a cryptographically weak
manner, so a third party could change the name in a cleartext message.
However if the message is cleartext there is nothing to stop him from
copying the body and giving it any signature he pleases, so this does
not actually gain the attacker anything.  After all, that is what
cleartext is.

If he changes the name it looks to the user and Kong like a new and
different signature.

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

    --
Yes:  For example this message contains a nested message.

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 
     J14rDU1EjUofOmSoHg1Ye0GF6/+6wdvxmCwMryE4 
     1jNcIP5kRfVPada+5w8zfIGEodi2Mrz80ZbvXsK1

>3) How are newlines and whitespace in the message body handled for
>signatures?
>	Canonicalized?  Ignored?  Not worried about?  

Not worried about, which is probably a seriously bad idea.  Will fix
in a later release.  In a later release I will canonicalise carriage
returns to Microsoft conventions, but not whitespace.  As this is
alas, a Borg only product, and will remain so for some time, such
canonicalisation will not break existing signed documents.

>	This affects not only reliability of signatures after
>	emailing, but also affects signing binary files.

Signing binary files is not yet supported, and will not be for some
time.

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

Yes

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

Yes

If Kong says a signature is good, and the public key agrees with a
business card then the guy who wrote the business card is claiming to
be the author of the message.  Actually you do not have to check all
43 characters.  It is sufficient to check the first ten characters, or
any ten characters.

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

If two keys have the same passphrase, but a different secret file,
then they will be two completely different keys.

However, the same passphrase, and the same file, means the same key. 
The secret file is merely concatenated with the secret file

>5) Is the format of the signature freeform, or do the newlines and 
>	whitespace have to be in their official locations? 

Minor flexibility.  You can add or remove leading blanks, and use
either lf or cr or both.  It is not totally rigid, but it is pretty
rigid. 

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     Uy36NbrQf/3FKV77cTtzFrHxsy0dcx9l6Svy/Fl5
     xP+I6vLpjTgacrHEqXoD3gv+HF9Tx4Zl+0yDGhQF