[PP-main] Cryptography as implemented by Flux

[Hans Petter Jansson]

It seems like cryptography is an issue to some here - although I think this
may be the wrong end to start working on, I'll give a brief outline of the
cryptography used in Flux, in the absence of proper documentation.

First of all, Flux has cryptographical functions that are easy to use and
don't leave much room for mistakes on the user's part. These implement
ElGamal for public-key and Twofish for symmetric ciphertexts. These
particular ciphers were chosen for the following reasons: Both are unpatented
and open, and both have excellent cryptographical merits (no successful
cryptanalysis for ElGamal, Twofish cryptanalized but no practical exploits
found). In addition, Twofish is very fast (faster than 3DES), as well as easy
to understand, leaving less room for mistakes. ElGamal is very slow, making
brute-force attacks difficult.

Encrypted Flux sessions can be established with minimal additional code on
the implementor's part, and work like this:

0) Server generates a random ElGamal key.

1) Client connects to server.

2) Server sends the public part of its ElGamal key to client.

3) Client generates a random Twofish key, encrypts it with the public key
   it received in step 2, and sends that to the server.

4) Server decrypts the Twofish key using its private ElGamal key, and makes a
   duplicate which is modified in a predictable way (so the keys used in
   two-way communications are different -> less ciphertext to work on if a
   brute-force attack is employed to recover any one of the keys).

5) Client makes a duplicate of its Twofish key, which is modified according
   to the same rules as used by the server.

6) Two-way communication begins.

Steps 2-5 are automated by Flux and invisible to the application programmer.
Twofish is used in 128-bit OFB mode. Initialization vectors (Schneier p.
194), although not required to be secret, are exchanged as part of the key
and thus secret.

The session can not be snooped by a third party, because the Twofish key
used is sent encrypted, and can not be decrypted by anyone but the holder of
server's secret key (which is not published anywhere).

At this point you have a full duplex connection, which schematically looks
like this:

Server <-- [Twofish key A] --- Client
Server --- [Twofish key B] --> Client

No authentication has yet been done - server and client could be anyone.

Authentication is left up to you; there are several possible schemas to
choose from, with varying degrees of security and work investment.

A) Client sends a user/password combination assumed to be known by the
   server. This is simple to implement, but less secure - and the server
   isn't authenticated this way. It's not susceptible to ciphertext replay,
   though, as sessions are encrypted with random keys (2^256 possibilities
   when initialization vectors are taken into consideration) and ciphertext
   blocks are chained (OFB).

B) Host keys are used. I recommend this. Here are the steps taken, in
   continuation of the session outlined above:

7) Server sends its public key to the client.

8) The client checks if it knows the key. If it does, the key is matched
   against the identity associated with the known key - if not, the key is
   added to its key/identity database.

9) Client encrypts a random block using the public key, and sends that to the
   server, challenging it to decrypt. This will determine if the server holds
   the secret key corresponding to the public key it sent in step 7.

10) The server decrypts the block and sends it back to the client.

11) The client verifies that the block from step 10 matches the one generated
    in step 9. If it does, the server's authenticity is established, and
    communication can begin.

Steps 7-11 are repeated with roles switched, to authenticate the client.

Note that identities are added in step 8. These identities can not be forged
by someone else later, even if they were listening to the complete session,
because:

- The session is encrypted.

- Even if you know the public key corresponding to an identity, you will
  still be required to prove your ownership of the corresponding secret key,
  which has not been published anywhere.

To take an example, step 8 is where SSH can ask you:

  Host key not found in the list of known hosts.
  Are you sure you want to continue connecting (yes/no)?

If you answer yes here, the key is added, and SSH proceeds to its
corresponding step 9.

Flux functions can be used to do all the key generation/handling required for
authentication.

Quite simple, really. What do you think?


-- 
coffeecocacolagravitywars - Hans Petter Jansson - amigadracoempirefluxstuff
toomuchsugarkingcrimsonemperorcrimzgoodbadandonedayitsallgonnaendupinflames