X-Git-Url: https://git.distorted.org.uk/u/mdw/catacomb/blobdiff_plain/b98200ad4460255bbdf921b5c99503eb6c505689..7c40480318648672af86e03bc72bc45c07194c37:/catcrypt.1

diff --git a/catcrypt.1 b/catcrypt.1
index ba3e266..d4ef3e1 100644
--- a/catcrypt.1
+++ b/catcrypt.1
@@ -44,7 +44,7 @@ is one of:
 .RI [ item ...]
 .br
 .B encrypt
-.RB [ \-a ]
+.RB [ \-aC ]
 .RB [ \-k
 .IR tag ]
 .RB [ \-f
@@ -54,7 +54,7 @@ is one of:
 .RI [ file ]
 .br
 .B decrypt
-.RB [ \-aqv ]
+.RB [ \-aqvC ]
 .RB [ \-f
 .IR format ]
 .RB [ \-o
@@ -470,6 +470,10 @@ in the current keyring; the default is not to sign the ciphertext.
 Write output to
 .I file
 rather than to standard output.
+.TP
+.B "\-C, \-\-nocheck"
+Don't check the public key for validity.  This makes encryption go much
+faster, but at the risk of using a duff key.
 .SS decrypt
 The
 .B decrypt
@@ -508,6 +512,11 @@ Write output to
 instead of to standard output.  The file is written in binary mode.
 Fixing line-end conventions is your problem; there are lots of good
 tools for dealing with it.
+.TP
+.B "\-C, \-\-nocheck"
+Don't check the private key for validity.  This makes decryption go much
+faster, but at the risk of using a duff key, and possibly leaking
+information about the private key.
 .PP
 Output is written to standard output in a machine-readable format.
 Major problems cause the program to write a diagnostic to standard error
@@ -544,7 +553,8 @@ All messages.
 All output written has been checked for authenticity.  However, output
 can fail madway through for many reasons, and the resulting message may
 therefore be truncated.  Don't rely on the output being complete until 
-.B OK is printed or
+.B OK
+is printed or
 .B catcrypt decrypt
 exits successfully.
 .SS "encode"
@@ -646,6 +656,18 @@ that, then \(en leaking intermediate values often voids security
 warranties.  But it does avoid the usual problem with separate signing
 and encryption that a careful leak by the recipient can produce evidence
 that you signed some incriminating message.
+.PP
+Note that
+.BR catcrypt 's
+signatures do
+.I not
+provide `non-repudiation' in any useful way.  This is deliberate: the
+purpose of signing is to convince the recipient of the sender's
+identity, rather than to allow the recipient to persuade anyone else.
+Indeed, given an encrypted and signed message, the recipient can
+straightforwardly construct a new message, apparently from the same
+sender, and whose signature still verifies, but with arbitrarily chosen
+content.
 .SH "CRYPTOGRAPHIC THEORY"
 Encryption of a message proceeds as follows.
 .hP 0.
@@ -663,8 +685,9 @@ Use the first bits of the keystream to key a symmetric encryption
 scheme; use the next bits to key a message authentication code.
 .hP 4.
 If we're signing the message then extract 1024 bytes from the keystream,
-sign them, and emit a packet containing the signature.  The signature
-packet doesn't contain the signed message, just the signature.
+sign the header and public value, and the keystream bytes; emit a packet
+containing the signature.  The signature packet doesn't contain the
+signed message, just the signature.
 .hP 5.
 Split the message into blocks.  For each block, pick a random IV from
 the keystream, encrypt the block and emit a packet containing the
@@ -683,4 +706,4 @@ That's it.  Nothing terribly controversial, really.
 .BR hashsum (1),
 .BR keyring (5).
 .SH AUTHOR
-Mark Wooding, <mdw@nsict.org>
+Mark Wooding, <mdw@distorted.org.uk>