Why?

A number of very good encryption systems (PGP, etc) exist, but for many people and situations, there are real problems with the use of these products.

The specific problems include the following:.

• PC's are commodity items - they are available in workplaces, in internet cafe's, in friends' houses and hotel foyers - yet most of these institutions do not allow casual users to install software - and the installed software suite is unlikely to include the user's preferred encryption system

• Even if the PC had all necessary software installed, many workplace and public PC's have the USB ports disabled, making it difficult for a casual user to access key-pairs.

• For casual users of public-access PC's, there is a significant concern that the PC might be running some form of monitoring software. Even if the machine is not running purpose-built monitoring systems, operating systems like MS Windows are notorious for squirrelling away information generated by users - a nightmare for the security-conscious user, and a huge boon for the forensic computer specialist! (try opening the 'history' tab on a internet cafe PC!!) Even if the user could securely generate cyphertext, one would not really want to store this on a hard-drive prior to inclusion in an email message.

• Fourth and finally, athough encryption systems such as PGP have been extensively tested, there is still the possiblity that the mathematical principles on which they are built will be compromised. This is a significant risk

Having articulated these problems, a need is also identified: The need is for an encryption system that:

• can be accessed by any PC user (assuming only basic access to the WWW)

• Offers a high level of security from cryptological attack

• Offers a high level of security from computer forensic techniques

 

---

How .. A step-by-step guide

Preliminaries...

• Agree with your correspondents on how to select seed text
• Agree with your correspondents on the keyphrase (which must be kept secret)
• Set up your free email account
• If possible, carry out a "test run".

Encryption

• Generate your random key
  • Go to the Key creation section of this page
  • Paste the seed text (remember that this must not be re-used) into the appropriate box.
  • Use the on-screen keyboard to generate your keyphrase, and paste this into the appropriate field in the box adjacent to the seed key box.
  • Generate the random key
• Go to the En/De-crypt section, enter your message in plaintext.
  This can be achieved in two ways
  • The computer's keyboard can be used.
  • The second and more secure approach is to use the on-screen keyboard to generate your plaintext, which can be cut and pasted into the I/O box.
• Generate the (hex) cyphertext
• FINISHED: You can now paste the cyphertext stream into the body of an email

Decryption

• Generate your random key
  • Go to the Key creation section of this page
  • Paste seed text into the appropriate box.
  • Use the on-screen keyboard to generate your keyphrase, and paste this into the appropriate field in the box adjacent to the seed key box.
  • Generate the random key
• Decrypt the (hex) stream
  • Go to the En/De-crypt section
  • Paste the (hex) cyphertext stream to the box.
  • "Decrypt".
• FINISHED: You can now view the plaintext.

---

What

Forensic security
To avoid the possibility of material being left on hard discs, it is important that the user be able to generate cyphertext without reliance on any disk-based files (either applications or data, and especially secret keys) and then cut-and-paste either plaintext or cyphertext straight into the body of an email message (using any of the other publicly accessible, web-based email packages)

Cryptographic security
All authors on cryptography, agree that XOR'ing plaintext with a key from a "One Time Pad" (OTP) is the most secure possible cryptographic system - in fact, it is mathematically provable that a true OTP system is unbreakable.

The difference between a true OTP system and other systems can be described as follows:
For a non-OTP system, a cryptanalyst attempts to find the key (the algorithm is usually assumed to be known), that will extract plaintext from a piece of cyphertext - If the cryptanalyst's efforts produce ANY plaintext, he/she yells "eureka" and pronounces the cypher to be (at least partially) broken. If even a fragment of clearly identifiable plaintext is recovered (eg, ".......robertson....") the cryptanalyst will be very pleased, and consider a major breakthrough to have occurred
The simple but profound logic embodied here is that if ANY plaintext is recovered from a non-OTP cryptographic system, the key found CAN RELIABLY BE ASSUMED to be the correct one.

For a OTP, the situation is different. Consider the following: a Cryptanalyst gains access to a piece of cyphertext 'CT1';
CT1 reads.. "X8ks23aFrewewT3hkeIm"
After much work, analysts in the team propose two keys:
Key1 "aFrewT3hkeImKdX8ks23"
Key2 "eImKdX8ks23aFrewT3hk"
When Key1 is XOR'd with the cyphertext, the plaintext "assassinate the king" is generated: When Key2 is XOR'd with the cyphertext, the plaintext "Raise acme bid $0.23" is generated
By definition, keys Key1 and Key2 have EXACTLY EQUAL PROBABILITY, and hence the two recovered plaintexts also have exactly equal probability of being the original plaintext. We can actually go further; For a given piece of cyphertext, ANY piece of plaintext (of the same length as the cyphertext) can be derived from a key, that has exactly the same probablility as all other keys of the same length! The original plaintext could just as likely have been "C U at the pub, Lucy". This is the true strength of the OTP.

Javascript algorithm
To meet the criteria for such a "One Time Pad" key, three criterial must be fulfilled: 1) the key must be as long as the plaintext, 2) the key must be only used once EVER, and 3) the key must be truly random.

It is easy for two correspondents (Alice and Bob) sitting is distant internet cafe's, to both access the same piece of text as a seed for their OTP key - for example, they can both load the BBC World Service's home page, and copy the text from the lead article. Such seed-text meets two out of the three criteria for a OTP (it can easily be as long as their message, and used only once)- but fails the third test miserably - it is not random.

The non-randomness of any plaintext is related to the known (non-random) frequency distributions of both individual letters, and of digraphs trigraphs & tetragraphs etc (sequences of 2,3 4 etc characters) - these latter cases effectively refer to dependencies of one character on previous characters in the text. A weakness would also be created if Alice and Bob always included some standard text at the start of their seed text - eg if they used the first science article from the BBC as their seed, and always included the standard phrase "From our Science reporter": This weakness was referred to as a 'crib' by the famous Bletchley Park cryptanalysts

To create a random key from the seed text, this javascript security system uses two principles:

• Each letter of the seed keytext is replaced by either a "1" or a "0": This approach effectively removes any possibility of individual character frequency analysis, but nevertheless generates a string that is quite unique to the seed plaintext. The process of substituting a "1" or a "0" for each letter, could be done simply on the basis of the least-significant bit of their ASCII value, but correlating the ASCII values with letter frequencies shows that this approach would not lead to somewhat different totals of "1"'s and "0"'s. The approach taken is to use the LSB for non-aphabetic characters, but for alphabetic characters to generate a list of characters in order of their frequency (within a large sample of text), and alternately assign "1" and "0" to successive letters in this frequency table. This approach ensures a close-to-even distribution of "1"'s and "0"'s.

• There is still the possiblity of frequency of patterns (of "1"s and "0"s) being detected: there is the more serious risk that an evesdropper (Eve) will guess or otherwise discover the (BBC news service) source of keytext seed. To avoid these possibilities, the user is asked to supply a (secret) keyphrase: Each letter of the key phrase is used in turn to define an "offset" value. The algorithm used to calculate the offset value, is (ASCIIValue%32 + 16): other algorithms are possible, but probably have few advantages. If the offset value is (for example) 17, then the 17th, 34th, 51st etc locations in the keytext seed (beyond the current index location) contribute their "1" or "0" to each of the 8 positions which form a single key character of the generated key. For the next character in the seed keytext, the next character of the keyphrase is used to generate a new offset value - and a new combination of 8 binary values. The offset algorithm always produces a value greater than 16, and it can safely be assumes that no correlation is possible between plaintext characters that are this far distant from each other. This approach avoids the second source of non-randomness in the seedtext - that of dependency between one character and those immediately preceding it. A long keyphrase will mean that identifiable series of offsets do not occur.

Integrity of source

Other cryptographic software distribution commonly requires distribution of MD5 or similar checksums from trusted sources to allow the user to be confident that their executables are trustworthy, and not 'doctored' by a malicious third party. For a javascript-based system this issue is much easier to address. A conscious decision has been made to locate the javascript for this security system within this page, to describe the code principles in detail, and to comment the code heavily. Users can readily see and verify the code that they are using.

 

---

Limitations    

Every computer system has limitations: the limitations of this system are:

• Javascript variable capabilities limits this system to SHORT messages (SMS length)

• At present, spaces are not removed from seed keys - this needs to be addressed.

References

Schneider B (1996)- Applied cryptography Second edition

Singh S (1999) "The code book"

Kahn D (1996) "The Codebreakers"

Basic Cryptanalysis. FIELD MANUAL .. DEPARTMENT OF THE ARMY

 

---

Copyright

The javascript is freeware - you may copy it and use it on your own site - PROVIDED you acknowledge me as the original author, and as the originator of the concept of using seed text and a keyphrase to generate a long, random key.

If you wish to modify the code, or make comments upon it, feel free to contact me.

© Lindsay Robertson lindsay@tech-vantage.com 14 October 2005