|
|
|
Use of the Program Specifying the Encryption Key Comparing Plaintext and Ciphertext for Randomness The Encryption Method |
| See also: A Practical Example of the Use of Email Encryption End-to-End |
Use of the Program
Please see here for a screenshot showing the software shortly before encryption of a message.
The message can be composed in the text box or a pre-written message can be loaded from a text file. You can (though you don't have to) append a file of any type.
The program creates an output file (the ciphertext file) containing the encrypted message plus the encrypted appended file (if any). This file always has a 'zip' extension, but it is not a ZIP file. You have to specify a folder where this file will be located, and a name for the file (the extension 'zip' will be added automatically).
Then clicking on the button 'Encrypt message and write it to ciphertext file' creates the output file (this normally requires anything from a few seconds to a minute), after which the message at right is displayed.
Then compose an ordinary email message to your colleague (using any email program or webmail client which supports email attachments), something like:
| Further to our recent conversation concerning our construction project, attached is the document (govt_app_guidelines.zip) with the guidelines for making the required application to the relevant government department. Please pass it on to your legal team for their comment. |
Attach the file created by Email Encryption End-to-End (EEE) — in the example shown in the screenshot above, the file 'govt_app_guidelines.zip' (which is not a real ZIP file but is the ciphertext file produced by EEE) — and send the message. (But not to a Gmail account, because Gmail automatically blocks all messages with an attached 'zip' file.)
If the recipient is expecting a message with an attached ciphertext file then there's no need to refer to it in the 'cover message'. Just compose some message about the weather, the price of gold or whatever (but nothing of possible interest to any eavesdropper), attach the ciphertext file and send the message.
When your colleague receives this message in his email client he notes that it has an attached file, and saves that file to any convenient location. Since it (always) has a 'zip' extension he might be tempted to run an unzip program, but instead he should run EEE, select 'Decrypt message received' and tell the program where to find the ciphertext file (in this example the file 'govt_app_guidelines.zip'). To decrypt the message he must know the key which you used to encrypt it. When EEE decrypts the ciphertext file it displays your message ("Since these days ..."). If it finds that there is an attached part (as in this example), it asks your colleague for the location of a folder in which to save it.
 | EEE then saves it in that folder, with the original name. Your colleague can then view the file which you sent (or if it is, say, an Excel spreadsheet or some other kind of file he can open it with the appropriate program). |
If the message you sent is intercepted somewhere between your PC and your colleague's PC an eavesdropper will see only a message about a document with government guidelines or a comment on the weather or whatever, plus an attached 'zip' file which the eavesdropper is unable to open.
After the ciphertext file has been created, it can be renamed. The decryption process does not depend on the particular name used when creating the file in EEE.
Specifying the Encryption Key
Email Encryption End-to-End uses a symmetric key encryption method, meaning that when a message is encrypted, the key required for decryption is the same as the key that was used for encyption (so "key" on this page may mean either "encryption key" or "decryption key", since they are the same).To specify a key click on the 'Key' button and a window will appear which enables you to enter the key:
No distinction is made between upper case letters and lower case, and spaces are ignored, so "Pass Word" is equivalent to "password". Keys may include non-English characters, e.g., "je rêve des chèvres françaises".
The longer the key the more secure it is. So it is advisable to use a key which is based upon some phrase that you can easily remember, but modified in some way (as in the example above) so that the key is not simply the phrase itself (which would make the key vulnerable to a 'dictionary attack').
Since the key in the example above includes words found in a dictionary, one might prefer to use a phrase with words broken in a way easy to remember, something like:
As you type the key a checksum is calculated and is displayed. If you use a key more than once then it is advisable to remember the final checksum. After entering a key an unusual checksum will show that a typing error was made. Failing to notice a typo when decrypting has no fatal consequences (you simply get an error message), but if you mistype the key prior to encrypting then the encrypted message cannot be decrypted using the intended key.
For the recipient of an encrypted message to be able to decrypt it, they must know the key, which must be communicated somehow. The way this is done depends on the level of security needed. You can simply phone the recipient and tell them the key. Sending the key by post is slower but perhaps more secure. Best is to meet the intended recipient in person and tell them or pass a note. If a meeting is not possible then a key can sometimes be agreed upon by referring to some item of information from your common past (e.g., the name of the restaurant where you used to have lunch together years ago). If you have never met, but have exchanged email then you can use the first few words from some email message (the older the better) which you have both kept.
Comparing Plaintext and Ciphertext for Randomness
Plaintext (even in compressed files) always exhibits some degree of non-randomness. An insecure encryption method will produce ciphertext which is more or less non-random, and this non-randomness can help an attacker to decrypt the ciphertext without knowing the encryption key.
Email Encryption End-to-End produces highly random ciphertext. After encrypting a message (and optionally an appended file) the button shown at right is enabled. Clicking on this will produce a window which graphically illustrates the randomness in the plaintext compared to randomness in the ciphertext. When the plaintext is mostly a ZIP file there is not much difference. But when the plaintext is entirely natural language text or a docx file then the difference is great, as illustrted below:
The randomness graphic is produced as follows: Each pair of bytes in a block of data is considered successively. Byte values range from 0 through 255. The first byte value is halved and is used as the x-coordinate in the 128x128 graphic, and the second byte value is halved and used as the y-coordinate, then a pixel is plotted at that x-y position in the picture. When the bytes have values which appear random then the pixels will be plotted at apparently random positions. When the byte values are not random (which is especially the case in data consisting only of text) non-randomness will be evident.
The "randomness measure" can range from near-zero to near-one, with a higher value indicating a higher degree of randomness.
The Encryption Method
Email Encryption End-to-End uses the encryption algorithm as used by our earlier cryptographic product, Cryptosystem ME6. This encryption method is described in The Cryptosystem ME6 Encryption Process. Cryptosystem ME6 was developed in Europe, was first released in 2001, and has been used continually since then, during which time no weakness in the encryption method has been discovered.A secure encryption method can be broken only by a brute force attack, that is, by trying every possible key. Whether this is feasible depends on (i) how quickly keys can be tested and (ii) how many keys have to be tested. Keys used with Email Encryption End-to-End consist of characters which can be typed at the keyboard (with no distinction between upper and lower case). There are 26 letters, 10 digits and (let's say) 28 punctuation and other characters, for a total of 64 typeable characters. The key can consist of up to 64 characters, but keys longer than, say, 32 characters are unlikely. If we consider only keys of not more than 32 characters, then the number of possible keys is 64^32, which equals 2^192. Thus it is reasonable to assert that Email Encryption End-to-End has in practice something like a 192-bit keyspace.
Since 64^32 is approximately 10^57, if a billion billion billion keys (10^27) could be tested each second then it would still take approximately a million million (10^12) times the estimated age of the universe (some 14 billion years) to test all possible keys. Email Encryption End-to-End can thus be considered secure against a brute force attack.
| Email Encryption End-to-End | Hermetic Systems Home Page |