General philosophy
==================
Pegwit is intended to be simple to understand, in contrast 
to PGP which in my opinion is over-sophisticated ( too many 
bells and whistles ).

Thus the number of primitives and options has been kept
to a minimum, possibly at some cost in convenience.

In particular the absence of key-rings etc. means that the
only 'state' information is the secret password, which can
be memorised ( and easily backed up on paper for people with
a poor memory ). Thus it is easy to use pegwit when you do
not happen to have your key-ring with you - all that is needed
is a copy of pegwit.exe, and knowledge of your password.

The drawback is that the responsibility for storing and verifying 
public keys is left to the user. This means that pegwit in its 
current form is most suitable for occasional use.

A GUI news/email front end for Windows-95, with an integrated 
address book containing public keys would be a step forward.
However I guess this would be a big job.

Security
========

The expected security of the public key component is 120 bits,
assuming good passwords. 

Even modest passwords (such as the 6 character challenge password) 
may require quite a large amount of computing effort to break, 
since testing a single password takes of the order of 1/10 second 
on a pentium. The manual recommends a minimum of 10 characters.

The security of the block cipher square should be 128 bits.

The security of the double-barreled version of SHA1 is expected
to be between 80 and 120 bits, assuming that SHA1 has no 
cryptographic weakness. Note that these 'birthday' attacks 
require the co-operation of the victim ( he has to be persuaded 
to sign a document which he has not changed ), and are one-off.

Implementation
==============

For exact details of implementation it is best to refer
to the actual source, but here are some details on how
pegwit works internally.

The main components are
   An elliptic curve over GF(2^255)
   SHA1
   The block cipher square

Here is an outline of how these components are implemented
and used.

(1) The elliptic curve

The field is represented as polynomials of degree 17
with coefficients which are elements of GF(2^15).

In the following, t is used for polynomials in the
small field, q is used for the degree 17 polynomials.

A reduction trinomial with coefficients in GF(2) is
used, viz. t^0.q^0 + t^0.q^3 + t^0.q^17 

The primitive polynomial used for multiplying in GF(2^15) is
t^0 + t^2 + t^15 

The equation of the elliptic curve is
y^2 + xy = x^3 + EC_B

where EC_B is the polynomial = ( t^0 + t^5 + t^7 ) . q^0

The above constants are all defined in ec_param.h

The order of the fixed point on the curve ( curve_point )
is a 241 bit prime ( prime_order ). These constants are
both defined at the top of ec_curve.c

The Nyberg-Rueppel scheme is used for signatures.

(2) SHA1 is used both for generating MAC's (message authentication
codes) and for key generation. A double-barreled version is used
to generate the MAC, the second SHA1 context is fed an extra 0
after initialisation. A 240 bit MAC is made up of 160 bits from 
the first context, and the remaining 80 bits from the second context.

To generate secret 240 bit multipliers, or for generating 128 bit
keys for square, SHA1 is used to repeatedly hash a structure 
consisting of 32 bit counter and a seed whose form depends on 
the multiplier being generated. 16 bits are used from each SHA1 
application. The counter runs from 1 to 15.

For generating a secret key, the seed is the SHA1 hash of the 
external secret key ( pass-phrase ).

For generating a multiplier for encryption, the seed is the SHA1
hash of the random input material, concatenated with the single-
barrelled SHA1 hash of the file being encrypted, and the value
returned by time(0) 

For generating a multiplier for a digital signature, the seed is the
SHA1 hash of the secret key, concatenated with the double-barreled
SHA1 hash of the file being signed.

(3) The square block cipher is used to encrypt data.
CBC mode is used, i.e. before encryption, the plaintext is
xor-ed with the block which has just been encrypted. 
A new initialisation vector is generated every 4k bytes, 
to allow the possibility of random access to encrypted files.
The IV is generated by encrypting a counter with square.

George Barwood