6 November 1999
Date: Sat, 6 Nov 1999 11:34:26 +0000
To: ukcrypto <ukcrypto@maillist.ox.ac.uk>
From: George Foot <georgefoot@oxted.demon.co.uk>
Subject: The BCF Cryptosystem
November 6th. 1999
To the ukcrypto mailing list:
The following document has been posted with the permission and the approval of the owner of this mailing list.
The document may be distributed at will if reproduced in its entirety and attributed to its authors who are George H. Foot and Michael J.D. Brown.
The document is in three parts which should not be separated as they are interrelated.
(1) The Employment of Encryption in E-Commerce and A Presentation of the BCF Cryptosystem: by George H. Foot.(2) An Informal Description of the BCF Symmetric Key Process: by Michael J.D. Brown
(3) A Critique of Public Key Cryptosystems: by George H. Foot
Comments would be much appreciated: Contact: georgefoot@oxted.demon.co.uk
Cryptosystems are available for the encryption of commercial and personal message traffic transmitted via electronic media and are satisfactory for present purposes: But the prospect is that encryption will be employed increasingly for the furtherance of E-Commerce introducing an environment in which business attitudes will prevail and new conditions of use will be encountered.
What is the present situation ?
We accept cryptosystems which we are told are secure because they have an adequate key length but which in reality may be totally insecure for reasons of which we are ignorant:
We accept cryptosystems which use much greater computational power than is truly necessary because of a lurking fear that otherwise security may be less than we require:
We accept the creed that the security of the cryptosystems we use is threatened by the growth of hostile computer power and that to employ a progressively greater and greater computing power ourselves in retaliation is our only protection:
We fail to protest at the squandering of computer power to achieve an ill-defined security which in many circumstances will exceed commercial needs and will impose unjustified costs on commercial transactions:
We fail to classify the security of various cryptosystems with respect to the degree of vigilance each may demand of human operators working under the stress of a commercial environment.
Suppose that we were to design a cryptosystem with emphasis on its suitability for E-commerce, what factors would influence our ideas ?
We have had this question under study for a long period during which we have been searching for the best answer keeping in mind the following precepts:
(a) There is no basic difference between E-Commerce and traditional Commerce in the manner in which trust and confidence can only grow gradually as a result of successful business relationships between two parties over a period of time.(b) A business man may receive a letter in an envelope which has not been opened and which may have been further protected in transit by registration or may have been delivered by courier. An electronic message in its encryption-cocoon provides an equivalent service and the busy business man requires nothing else to continue his activities. He is alert to suspicious circumstances because of his business training and experience irrespective of the manner in which his correspondence may have been transported.
(c) The identity of the parties in contact is rarely in doubt in conventional business transactions and in any case is verifiable by regular business methods -- for example the telephone (in future the video-telephone), notarization of documents, bank references, mutual acquaintances and personal contacts. The anonymity of the Internet lends itself to fraud and imposes a burden of vigilance on businessmen which to some extent offsets its advantages.
(d) Experience and common sense indicate that the only way to ensure that no third party has tampered with Keys is to ensure that no third party (certified or otherwise) ever has access to those Keys. Keys should be kept securely in-house and preferably discarded or modified after every occasion they are employed.
(e) It is only a minority of documents which need encryption and it is a needless complication and in practice also a waste of resources and an additional expense to encrypt everything. Furthermore a reduced level of security may sometimes be entirely adequate for commercial purposes when security is required only for a short period.
(f) The derivation of security by means of a mathematical algorithm is common practice but the underlying fear which can never be removed is that security may have been breached by cryptoanalysis and that this success may have been concealed. (g) The idea that the authenticity of a message can be verified by an electronic signature which combines elements of the Keys of both sender and receiver is ingenious but has neither been tested in practice nor at law. It should be regarded as a separate feature to be added to a Cryptosystem at an appropriate time when international agreement has been reached.
The outcome of our studies and experiments over a considerable period is a proposal for a Cryptosystem for commercial use (that is for non- military applications) which for convenience we call BCF.
BCF is a Cryptosystem in which a key stream generator produces a random sequence of data which is combined character by character with the text of the message to be processed. The Exclusive-OR operator (commonly denoted by EOR or XOR) is used for the combining process.
BCF is a practical embodiment of Maurer‘s Randomized Stream Cipher: (See U.M. Maurer "A Provable-Secure Strongly-Randomized Cipher": EUROCRYPT 1990).
As BCF is intended for general use with all types of computer data, the 'characters‘ introduced by its bit stream generator have been chosen to be 8-bit bytes which can assume values between 0 and 255 decimal.
(3.1) The BCF NUMBER PAD
The distinguishing feature of our proposal is the creation of a Pad of Random 8-bit Numbers which is intended to be made freely available throughout the world at low cost and which itself needs no security protection.
A BCF Number Pad is available as a single file of approximately 600 Megabytes on a Compact Disc of the type which is now universal. The Pad may be used from a CD Drive or alternatively it can be transferred to a Hard Disc.
The Number Pad we use ourselves has been prepared with elaborate care. It passes all known tests for randomness and as it incorporates an element of physical randomness it is unique.
To ensure that everybody has exactly the same Number Pad we offer to make available the Number Pad which we employ which is known as X2. This is copyrighted and authentic copies will carry the BCF Trade Mark for protection against illicit imitations.
It is of critical importance that only BCF Number Pads prepared and approved by us and bearing the BCF Trade Mark should be employed to maintain a high and uniform standard of security for BCF.
(3.2) THE BCF MESSAGE PAD.
A necessary step to BCF encryption is the construction of a Message Pad. For this purpose a string of numbers equal to the length of the message to be transmitted is downloaded from the BCF Number Pad (which is in a CD Drive or on a Hard Disc) starting at an arbitrary position within the Number Pad indicated by a Pointer.
A second similar number string is obtained commencing at another position in the Number Pad (chosen randomly and indicated by a second Pointer) taking care that the two strings do not overlap.
A third number string is then obtained in similar fashion and the process continues until the required number of strings is available =- typically using about twelve Pointers to obtain twelve number strings, none of which overlap.
All these number strings are then EORed together to form a Message Pad which is unique to the particular Message for which it is has been created.
The Message itself is then encrypted by EORing the Message with the Message Pad.
(3.3) SECURITY OF THE BCF CRYPTOSYSTEM
There are approximately 6*108 positions in the Pad from which to choose the start of each string of numbers.
With two strings the number of different Message Pads possible is 36*1016:
With twelve strings, the number of different Message Pads theoretically possible becomes about 2 * 10105 but is reduced by the need to avoid overlapping and by other considerations to about 10100 which is truly a very formidable and impressively large Message Pad space to explore.
Anyone new to the concept of such large numbers will begin to realize its size and significance by writing "1" and following this by writing "0" one hundred times . Note that the degree of security can be adjusted by the software as circumstances require from an adequate but relatively low level to an enormously high value merely by changing the number of strings employed to form the Message Pad. This facility to adjust security is of assistance to the business user in circumstances where lower levels of security are adequate or where governments impose limitations on the level of security which can be employed.
Paradoxically the facility to adjust the level of security can in some circumstances effectively increase security. Message Pads produced by different numbers of Pointers are entirely different although they are always the same length as the message in plaintext. It follows that anyone attempting to decrypt an intercepted message without knowledge of the number of Pointers is at a serious disadvantage.
With so many Message Pads available it is highly unlikely that the same Message Pad would ever be used twice even if the cryptosystem were in continuous use worldwide.
This high degree of security can be obtained without employing algorithmic complexity. Moreover it is demonstrably evident that there are no Back Doors !
Note that the disclosure of any Message Pad (for example by carelessness or stealth) will reveal only the one message using that Pad but will not reveal anything else. No messages transmitted either earlier or later are compromised.
Man-in-the Middle activity requires elaborate preparations which are more probably encountered in political intrigue than in business correspondence. Without full knowledge of BCF Keys and BCF Message Pads such as might be obtained by commercial espionage it would be difficult in the extreme to substitute or modify messages (especially in a switched network with packet transmission) and early suspicion would arise in the normal course of the exchange of business messages.
The high security provided with BCF ensures the safety and privacy of a message during transmission. (See also "One-Time-Pads" below).
(3.4) THE BCF KEYS
Contact between two parties at different locations wishing to communicate securely with each other is made initially by means of a Diffie-Hellman exchange. Either party may initiate the exchange between them of Part Keys with the outcome that a complete BCF Key becomes available for the use of both parties.
BCF Keys are known as Part1-Keys and Part2-Keys. A Part1-Key has no value unless combined with a Part2-Key to constitute a complete BCF Key. The Key size must be sufficiently large to ensure that the Key itself does not constitute a weakness to security. This is an area where standardization becomes important and we propose that BCF Keys should always be 2048 bit size.
(3.5) BCF ENCRYPTION AND DECRYPTION.
The BCF cryptosystem can be adapted to all computer platforms by writing appropriate software and can provide secure encrypted message transmission between one computer terminal and any other computer terminal interconnected by any transmission medium. The BCF cryptosystem can also be used for encrypting computer data for storage.
When a message is to be encrypted an additional Key is generated. This is the Message Key and it may be derived in many ways. The method used in the BCF prototype software has been to employ the output obtained after processing the computer‘s real time calendar and clock.
The secret BCF Key and the Message Key are then mixed to form a Session Key which is unique to every message or to the messages despatched during one transmission session.
The Session Key is used to determine the initial values of the BCF Number Pad Pointers taking care that no two Pointers have the same initial value.
The number of Pointers is determined by the operator-specified level of security in conjunction with the length of the message. Strings of numbers are downloaded from the BCF Number Pad starting at each Pointer position with verification that the strings do not overlap.
The BCF Message Pad is created by EORing the strings of numbers and the encrypted message is then obtained by EORing the message and the Message Pad.
The decryption process is essentially the reverse of encryption.
(3.6) KEY LOCATION
Public Key Cryptosystems are a vaunted solution for the problems anticipated if encryption were employed extensively for privacy in E- Commerce and in personal E-Mail. But there are associated difficulties in Key Distribution, Key Revocation and Key Authentication which have not been solved and which are the subject currently of much discussion and controversy. (See "A Critique of Public Key Cryptosystems" by George H. Foot which appears below).
The BCF Cryptosystem rejects the principle of advance publication of Keys by third parties whether in electronic or in printed form.
A far better approach is to consult the Web Page of the party with whom it is desired to communicate in a secure manner.
Web Pages have become so commonplace that it is now exceptional to find a commercial company of importance which does not publicize its activities in its Web Page. There are already a vast range of Web Pages owned by organizations of every character and by private individuals and the number of Web Pages is growing at a phenomenal rate.
Most Web Pages list ways in which a company or other organisation can be contacted and contact is possible in many cases from the Web Page itself.
A message to the company from its Web Page will on request produce a reply supplying the current KEY for whatever cryptosystem that company is employing for secure transmissions.
A Key obtained from a public Web Page inspires more confidence that a Key obtained from more shadowy sources and deservedly so. Furthermore the Web Page has the inestimable advantage that it can carry information instantly on Keys revoked because they are no longer secure -- a severe problem otherwise.
In fact the advent of Web Pages can be held to make obsolete other proposals for Key distribution and certification which are controversial and have not yet been brought into use.
Lastly do not forget the remedy for many business problems: A simple telephone call will in 99.9% of cases provide the correct answer.
(3.7) BUSINESS FEATURES OF BCF
A BCF Key is available for the exclusive use of the two parties which have created that Key. However, if desired, a Group BCF Key can be created very easily and distributed to members of the Group.
Note that a messages not intended for all members of a Group can continue to be sent securely between any two members of the Group. In fact some members of one Group can be included in another Group without Group messages going astray. Such facilities are valuable for communication between companies with branches at many locations.
BCF software may be written as two separate programs: The first is Administrative and the second is Messaging. This arrangement allows Key creation and storage to be restricted to designated company personnel.
Such features and many others can be provided by software writers at the discretion of the business management.
BCF is well suited to E-Commerce and to a business environment generally,
Another mode is available for the transmission of encrypted messages between two parties and this is known as BCFX.
The first step is to establish a BCF Key between two parties if such a BCF Key does not exist already. Let us call the parties A and B.
A Message Pad is then created using the number of Pointers appropriate to the level of security desired and of a length which is convenient -- for example a 1 Megabyte or a 10 Megabytes Message Pad could be chosen. But at this stage no Message is concerned.
The Pointer values are then transmitted from A to B as a BCF encrypted message enabling an identical Message Pad to be created at B.
The Message Pads at A and B being identical can be utilised as a One-Time-Pad by EORing the message with the Message Pad at A to produce ciphertext which is decrypted on arrival at B by EORing the cipher text with the Message Pad at B.
That part of the Message Pad employed at A and at B for encrypting and decrypting a message is then expunged as it must be used once only.
The procedure for the next message is similar but the starting byte is the byte following the last byte used by the previous message.
A similar but different Message Pad is created for transmission in the return direction B to A.
It is to be noted particularly that encryption and decryption with BCFX are simple EOR operations which can take place at the maximum speed of which the processor and transmission link is capable -- which means in practice that bandwidth is the only limit to speed of message transmission and neither encryption nor decryption reduces that speed.
When all of a BCFX Message Pad has been exhausted it must be renewed.
[(5) not used]
It will be observed that with BCFX the Message Pads are used in the same manner as One-Time-Pads. But a distinction is necessary and it should be noted that BCFX is not identical with a One-Time-Pad system in the usual meaning of that description. A step closer to One-Time -Pad operation is possible if the Number Pads employed with BCFX are not universal but are created for the sole use of two parties or of a particular Group of parties. But such restrictions bring the penalty that the Number Pads must be held under secure conditions.
Nevertheless BCF cannot be out-classed in matters of security because BCF software can also include true One-Time_Pad working. In that mode of operation BCF Number Pads must be used once-only and must be held securely at all times -- a considerable inconvenience.
Nevertheless in the circumstances that a company representative were travelling abroad with his laptop computer it would be no hardship to place a set of ten specially prepared BCF CDs in his jacket pocket before leaving his home base which would provide him with 6000 MBytes of true One-Time_Pad communication with his company -- without restriction on his use of BCF or BCFX for other communications.
BCF is a secure Cryptosystem of attractive simplicity suitable for universal application and with design features such as a Variable Level of Security, Group Control of Keys, etc. is well suited to E-Commerce.
An advantage of BCF is that its security does not depend on the use of a mathematical algorithm. It is demonstrably evident that there are no "Back Doors".
BCF can be used without restrictions on all computer platforms and will work satisfactorily with older as well as fast modern computers without the necessity of any hardware modifications. A CD Drive is required.
The principal features of BCF and particularly its encryption/decryption processes have been tested with appropriate software and function well with surprising speed.
A BCF encrypted message has the same length as the plaintext before encryption and no extra loading of traffic circuits occurs. A new form of BCF called BCFX encrypts and decrypts messages instantly obviating any delay in transmission or any loss of transmission circuit capacity.
BCFX destroys its Keys and other evidence of encryption after each message is decrypted. This is a security provision but is also a defence to a subsequent demand by any authority to produce information about Keys inasmuch as Keys cannot be produced because no Keys remain.
BCF and BCFX facilities can be provided in software at little cost and no new hardware is required. It is hoped that this description of BCF and BCFX will generate sufficient interest to make it possible to produce BCF as a commercial package.
Basic Principles
----------------
The functional requirement for the BCF secret key process is to provide initial values for the pointers indicating the positions within the Number Pad from which key stream data is to be extracted. Every message must, with a high degree of confidence, employ a different set of initial values than messages sent previously.
A legitimate recipient must be able to determine the initial values easily, whilst an adversary intercepting the message must employ brute force searching of their possible combinations until readable plaintext emerges from a trial decryption.
BCF derives the initial pointer values from an array which contains a proper permutation of all possible byte values. The permutation is generated under the control of keys, both secret and overt, to the privacy of each encrypted message and guard agaist repeated use of the same permutation array for subsequent messages.
The use of a permutation array as a source of data for establishing an encryption process is evidently of quite general application.
Permutation under Key Control
-----------------------------
On completion of the initial setup process the permutation array consists of 256 entries containing a disordered set S of one each of the decimal values 0..255.
As already stated, disordering the permutation array is controlled by keys, each consisting of a string of byte values, repeated if necessary to fill an array K of 256 byte entries. In the prototype BCF software the secret keys are of a standardised length, 256 bytes or 2048 bits. Since the number of possible permutations of byte values is a number of around 1680 bits in length, it is evident that the standardised secret key length is more than adequate to allow the full range of permutations to be generated.
The disordering is performed by the setup stage of the algorithm employed by the ArcFour cipher (which is reputedly identical to the widely-used commercial RC4 system):
initialise permutation S-array:
FOR i=0 TO 255
S(i)=i
NEXTpermute the S-array:
j=0
FOR i=0 TO 255
j=(j + S(i) + K(i)) MOD 256
SWAP(S(i),S(j))
NEXT
In passing it is worth observing that, in spite of some assertions to the contrary, RC4 (and thus ArcFour) is not subject to any third party intellectual property rights, since would be many hundreds of older generation programmers who could testify that the algorithm was common knowledge and practice in the mid-1960s for the production of sampling arrays for Monte Carlo simulations. This fact may be the reason why the company chose to protect RC4 by simple trade secrecy, rather than attempting to obtain patent protection.
Secret and Message Keys
-----------------------
Each pair or closed group of authorised users share a secret key, consisting of 256 bytes of data which are generated and distributed as computer data files under a physical and procedural security regime appropriate to the user application. No specific method is prescribed, though the prototype software is capable of generating an exchange of email messages to perform a Diffie Hellman exchange using the 2048-bit modulus prescribed at Section 5.3.3 of the IETF IPSEC Working Group Simple Key-Management for Internet Protocols (SKIP) draft document dated 21st December 1995. Within a commercial company environment we would expect that central generation and physical distribution to the various departments would be preferred.
When a message is to be encrypted an additional key, intended to be unique to that message is generated. This, the message key, may be derived in many different ways: an algorithmic sequence generator, or the outcome of processing the computer's real time calendar and clock immediately suggest themselves, the latter being employed in the BCF prototype software. The message key is inserted in plain view in the header of the encrypted message.
The secret and message keys are then mixed as follows:
1. Perform the normal "initialise permutation S-array" process, as defined above.2. Perform the "permute the S-array" process as defined above with the K-array containing the secret key.
3. Perform the "permute the S-array" process as defined above with the K-array containing the message key.
4. Perform the "permute the S-array" process as defined above again with the K-array containing the secret key.
One important advantage of this method is that both the secret key and the session key can be of any length up to 265 bytes. A second, and probably more significant advantage is that an adversary's knowledge of the message key is of no assistance to him, since its effect is cloaked in both directions by the permutation of the S-array under the control of the secret key.
The final outcome of the permuting of the S-array is equivalent to a session key in common cryptographic practice because it is used to determine the initial values of the BCF pad file pointers for the encryption of a single message further work is evidently necessary in contemplation of the proposed UK E-commerce legislation to avoid the necessity of disclosing the secret key to a LEA serving a decryption notice upon a BCF user.
The fact that the now scrambled contents of the S-array are a proper permutation is of particular value in ensuring not only that no two pointers ever receive an identical initial value (which would cancel out both their contributions to the security level, but also significantly reduces the chance of parts of the encrypting key streams coming from overlapping parts of the pad file if the initial pointer values lie too closely together.
The user-specified degree of required message security and the length of the pad file to be employed determine the number of pointers required. Initial values are determined by taking bytes in their permuted order from the S-array and depositing them in turn into the pointer variables.
A number of schemes are possible, but in the BCF prototype software each pointer is initially formed as a 4-byte integer, their most significant bytes being a single byte taken from the S-array (and thus guaranteed different for each pointer), the next most significant bytes are formed by EORing together more bytes from the S-array taken in pairs, and so forth. After the pointers have received their complete complement of bytes their values are right-shifted to bring scale them to suit the size of the pad file.
Further development of the secret key process described above is possible, including the employment of a multiplicative congruential sequence generator to distribute the secret and message keys into the K-array in a pseudo-random fashion. Such enhancement could be a significant benefit if the keys are short. However, as it was decided to use full-length 256-byte secret keys as standard practice in the prototype BCF software, the merits of such an enhancement have not been a material issue and hence have not yet been subjected to a detailed evaluation.
A additional enhancement of the process of disordering the permutation array is to replace the single secret key file with the option of specifying a secret key directory, containing a number of individual key files, which would be applied in canonical order at Steps 2 and 4 of the mixing process outlined previously. This idea offers the prospect of representing a large number of secret keys employed within an organisation by a relatively small number of actual key files. For example, with a set of 8 individual key files, 256 different key sets could be constructed by the omission or inclusion of the files in a key folder. Key sets of this type could be structured to provide disjoint sub-group keys for controlling access to multiple address encrypted email messages.
SUMMARY:
A presentation of the drawbacks inherent in Public Key Cryptosystems and the difficulties and hazards which can be expected to arise in practice from the point of view of an operator in a commercial environment.
The reader needs to be familiar with the concept of Public Key Cryptography.
(1) INTRODUCTION
Public Key Cryptography employs two Keys one of which (The Public Key) is published and the other (The Private Key) is kept secret, The Public Key is available to anyone who wishes to communicate securely with the owner of the Private Key.
Although Public Key Cryptography is a brilliant invention there are several problems which have appeared for which no good solutions have been found.
(2) THE PRIVATE KEY:
The owner is expected to keep his Private Key secret for all-time for otherwise deception is possible by anyone who becomes possessed of that Private Key.
It is very difficult to keep something secret for an extended period of time when it has to be employed every day and guarded every night -- the more so obviously when the owner of a Private Key is a company or other organization engaged in large scale business at numerous locations.
In daytime the Private Key has to be employed in encrypting messages during which it is present and accessible from computers or possibly it can be extracted from connecting cables or magnetic fields. The secret is probably shared amongst employees some of whom may become disaffected with the company for which they work and maliciously reveal the Private Key to competitors and some of whom may have been planted within the company by a competitor for the sole purpose of learning its secrets.
Apart from other considerations the considerable vigilance which is necessary to operate any security system cannot be maintained at a sufficiently high level and be continued ceaselessly over long periods by human beings who are concerned with day-to-day problems relating to their duties and distracted not infrequently by various personal worries. Lapses on the part of operators are the commonest weaknesses in any security system.
It is the vulnerability of the Private Key which is the inherent weakness of a Public Key Cryptosystem.
The loss of a Private Key for whatever reason is a disaster which in practice is likely to occur and almost impossible to prevent.
(3) THE PUBLIC KEY:
If Public Key Cryptography were in common use worldwide, the number of Public Keys required would be very large.
It has been suggested that a Central Register should be established which would hold Public Keys and issue them on request with a certificate of authenticity.
Who is responsible for losses incurred if the Key issued is not valid? Will there be separate Registers in each country? Will they hold Keys of nationals of other countries? Will they charge for their services? Will they advertise? Will the need for commercial viability affect their integrity? Will they maintain the accuracy of their records on a daily basis? An hourly basis? Continuously?
Most countries are loath to surrender any of their traditional powers to monitor covertly all electronic communications between their citizens. In large part this attitude stems from the desire of clandestine intelligence agencies within government to retain their privileges.
It is a legitimate fear that a tolerant attitude by government initially will be followed by legislation which progressively restricts the free use of cryptography in the civil sector.
(4) THE DANGEROUS KEY
A major weakness in a Public Key Cryptosystem is the difficulty of withdrawing a Public Key which is no longer valid.
The problem is simple to explain but an effective solution does not exist and possibly is impossible to find.
The difficulty is that a Public Key which has been in use for some time will exist in many forms: On the computers of the numerous customers of a company some of whom trade with the company regularly, some spasmodically and some no longer: On the computers of lawyers, government departments, trade associations, competitors, and endless other organisations with which the company has contacted in the past: On newspapers, TV advertisements and other publicity material used by the company at any time. On storage media of which there is no record.
It follows that there is no way in which a Public Key can be withdrawn with assurance that it will cease to be employed.
It is also to be remembered that security considerations require that Keys should be changed frequently which implies that worldwide use of Public Key Cryptography would require that thousands of Keys be changed every day for one reason or another -- which in fact may be infeasible.
It is significant and disconcerting that current discussion centres on establishing methods for Key Distribution without consideration of the much more intractable problem of Key Annulment.
(5) REALITY
Why use a Public Key Cryptosystem ?
There is an appeal in the idea of Public Keys which can be published by everybody and become available to everyone else but the idea is more romantic than sensible.
Our need is for a simple method of encrypting those portions of our electronic communications which need protection from other eyes. For that purpose Public Key Cryptosystems are subject to all the drawbacks which have been described above.
Cryptosystems which are practical and satisfactory for use in a commercial environment should not require the publication and distribution of Keys in advance of message transmission. Cryptosystems are available which generate new Keys at the time of message despatch and discard those Keys immediately after use: Such cryptosystems should be preferred.
George Foot.
-- George Foot
georgefoot@oxted.demon.co.uk
http://www.oxted.demon.co.uk