FIRST AND FOREMOST
==================

    Caesarion was primarily designed for secret-public-key applications.
Naturally, it can also be used as a non-secret public-key system.
However, if your requirement is high security, I wouldn't advise using
non-secret public-keys.

HOW TO USE THIS SOFTWARE
========================

NOTE: Basic knowledge of shell-commands is assumed.

    Initially, every user must execute the cion_keygen(1) command to generate
their public and private RSA keys. By default, the cion_keygen(1) command will
generate a public-key which is likely to be significantly larger than
1024-bits, as required for long-term security.
    The cion_keygen(1) command allows you to specify what size of public-key
to generate, for example "cion_keygen -b 4096" will generate a public-key which
is at least 4096 bits in size. During execution of this command, you will be
prompted for a password. Think of a password which nobody else could guess,
and preferably make it fairly long. The password can be a "pass phrase" in
the sense that it can be a sentence of words with spaces. The password may
contain control characters, escape characters, function key characters, etc.
The only keys you can't enter into the password are the keys used for
job-control, e.g. ^C, ^Z, etc. This password is used for encrypting your
RSA private-key, and has to be entered every time the computer needs to
access your RSA private-key, since it is only ever stored on the hard-disk
in encrypted form. It is very important that you do not forget this password;
if you forget this password you will have to regenerate your public and
private keys and securely redistribute your new public-key to the parties
with whom you wish to communicate.
    As of version 9 of Caesarion, the cion_keygen(1) command provides the
option of encrypting your public-key. This is for high security secret-
public-key scenarios. If you do choose to encrypt your public-key, the
cion_fdecrypt(1) and cion_fencrypt(1) programs facilitate decrypting
and encrypting your public-key, to allow it to be transferred to the
clients with whom you wish to securely communicate. Exactly how you go
about doing this is outside the scope of this document and is entirely
upto yourself (and your clients). However, one important point which
should be made is this: the password you choose to encrypt your private-
key and public-key(s) should be known only to yourself and should not be
communicated to anyone. Use the cion_fdecrypt(1) command to decrypt your
public-key, securely communicate it to your client(s), and then they would
encrypt your public-key using cion_fencrypt(1) and a password of their choosing.
    For the highest security the password you use to encrypt your own public-
key, and the copies of your clients public-keys, should be different to the
password used to encrypt your private-key.
    Once cion_keygen(1) has finished executing, it will have created a new
directory (e.g. /home/robin/caesarion) in which there will be two files:
"private-key.L14" and "public-key". If you chose to encrypt your public-key,
then the name of the public-key file will be "public-key.L14". Don't ever try
to edit these files. The ".L14" filename extension is used to denote a file
which has been encrypted with Leopard14-CipherPacket.
    The "public-key" file contains your RSA public-key in binary format.
This is the information which both users of this cryptosystem must securely
exchange before any E-mail can be sent. So for example, if I (robin) want to
securely communicate with Harry, first we must both securely exchange/swap
our public-keys. Doing this over the internet is fraught with danger and
should only ever be done as a last resort.  Once I have obtained an authentic
copy of Harry's public-key, and Harry has obtained an authentic copy of my
public-key, we are then both in a position to send and receive secret, and
digitally signed, electronic mail. The digital signature system provides both
user authentication and message integrity verification. It means that, for
example, I can verify that a message received came from Harry and only Harry,
and also that the message received from Harry has not been tampered with in
any way.
    In practice, the public-keys belonging to other parties with whom
you wish to securely communicate must reside in e.g. /home/robin/caesarion.
For example, if I receive an authentic public-key from Harry, I would place
it in my "caesarion" directory, calling it "harry".
An ls(1) of the caesarion directory would then reveal:

total 6
-rw-r--r--  1 robin  robin   378 Apr 29 21:55 harry
-rw-------  1 robin  robin  1227 Apr 29 21:53 private-key.L14
-rw-------  1 robin  robin   380 Apr 29 21:53 public-key

Likewise, Harry would have a copy of my public-key in his caesarion
directory, probably called "robin".
    Once the users of this software have generated their public and private
keys, and securely exchanged their public-keys, they are then in a position to
securely communicate with each other using the cion_encrypt(1) and
cion_decrypt(1) programs. Read the the manual pages, or just execute
these commands with no arguments for usage diagnostics.
    I strongly recommend that users of this software /secretly/ exchange
their /encrypted/ public-keys /in person/.
    A very useful feature built into the cion_encrypt(1) program can be
accessed via the -m command line option. This command line option makes
the program obtain the plaintext message via direct keyboard input, as opposed
to a file on your hard-disk. When entering your plaintext message using the -m
option, enter ^D (control-D) after a newline/ENTER to end input of the message.
There are two important points to note about the -m command line option:
	(1) Since the plaintext message is input directly from the keyboard
(instead of a file) there is no risk of someone being able to analyse
your hard-disk and retrieve the plaintext message via that route.
	(2) The cion_encrypt(1) program does not echo back the characters you
type in from the keyboard, and thus defeats CRT surveillance.
    An example use of the -m command line option would be:

    cion_encrypt -m -t harry

    Note that the cion_encrypt(1) program requires use of either the -i
or -m command line option.
    Users of this software might want to gzip(1) the ciphertext produced
by the use of the cion_encrypt(1) program, since its output contains lots of
hexadecimal encoded data, and will compress nicely.
    Users of this software might want to use the uuencode(1) program on
the ciphertext produced by cion_encrypt(1). This way, at the receiving end,
the uudecode(1) program will automatically ignore the mail-headers, e.g.

    uuencode ciphertext ciphertext | mail harry

Alternatively, just attach the ciphertext to the email using PINE, etc.
