An excerpt from the book Advanced Handwriting Cryptography..
The following principles or rules are not necessarily in the order of priority — all of them are important. I’m numbering the rules just for easy following and in the order they come to my mind.
Never keep plaintext and encrypted text together. Never show off anyone how beautiful is the encryption method representing your name or else. If it’s unavoidable for whatever social reasons then show it generally writing down a wrong thing in a wrong way.. and if asked much later what does it means then simply say you probably made a mistake and can’t understand.
I can imagine that after creating a personal code the excitement of the achievement may trigger the emotions to show it someone, but it may cost you lost privacy and/or extra work to create a new code. You may only show the exact encrypted writing to someone you’re planning to share the particular code with.
You should always encrypt as little text as reasonably possible, encrypting only the parts which need to be encrypted, the related parts of text which would give out the information about context of the encrypted text, possible sources of the encrypted text and other content having references to the encrypted text.
The less data you encrypt and fewer references you leave about the encrypted text the less vulnerable it will be for attacks by cryptanalysis. When encrypting whole the context is impractical then don’t insert the encrypted part directly into plaintext — instead insert an encrypted reference to the place where you hold the actual encrypted part belonging to the document.
Never write a script without including at least a minimum amount of information noise — the symbols and extensions which actually mean nothing. Write into a cipher text about 1/5…1/10…1/15 of symbols as a noise and varying the amount of the noise from place to place.
Using the noise level and quality of it properly makes exponentially harder to crack the code by cryptanalysis while still keeping the script easy to read without affecting the process of decryption.
Never write down text, specific names and codes in the same script using the same encryption method/pattern or set of symbols.
Having an accidental access to one of them will make it easier to crack the other part of the script if encoded with the same method and/or set of symbols. It doesn’t mean you will always need to write down different data with completely different encryption methods, you need at least to use different keys of encryption within the same method.
Create a simplified public set of symbols to write down stuff temporarily but fast and still quite securely while others are watching and may guess the content.
Later you can rewrite the data in another place with private and highly secure code while destroying the public version of the same script.
Never correct encryption errors by writing a correct symbol above the wrong one. Include in your encoding method hidden (also encrypted) tools for backward deletion, insertion, replacement and other correction symbols, and special signs indicating errors if placed in the right position but otherwise used as noise. If an error isn’t important leave the error uncorrected. If not possible to leave an error in and to correct it then write the data again correctly with other symbols leaving the error untouched. If none of the above works for you then destroy the wrong symbols leaving no traces of them before writing correct versions above.. or destroy whole the script and write again.
Indicating your errors is a good help for cryptanalysts, leaving the errors into the script is the cryptanalysts’ nightmare.
Never use classical grammatical signs within encrypted script. All the signs like periods, commas, apostrophes, dashes and any other signs, also real positions of spaces, line breaks and other grammatical rules must be encrypted and hidden within encryption. An encryption must give no hint whatsoever what it is about. Don’t even use any classical signs in wrong places as a noise — use only random false spacing for breaking and combining ‘words’ into the blocks with not the real length.
Placing classical signs within encrypted script is an excellent help for cryptanalysts to guess the content. In some cases you may use the classical signs as a noise (in wrong places), to confuse others, but if you’re not careful enough you may give away some information unwillingly just because of your habits (dropping accidentally the signs into right locations).
Never highlight any part of the encrypted script in classical style for easy following. For highlighting use encryption rules you could easily spot if necessary but which wouldn’t look special to others.
Highlighting parts of the encrypted text, like underlined or bold script, is an excellent help for cryptanalysts to guess the content. If you do need to include highlights for the text you’re encrypting then you must create corresponding, visually hidden rules and code symbols for use within the encryption, including code representations for colors, size, font, background, etc.
Never use within encryption the actual length of encrypted words and even sentences to make it look better and easier to read.
Writing encrypted script with the actual length of encrypted words is the best help for cryptanalysts to guess the content and will greatly diminish the strength of encryption. In some cases, writing long pieces of text, it will render the use of almost all the other precaution rules practically pointless — by the frequency of words and the rules of grammar in a language a computer program will easily be able to make sense of your encrypted text.
Never back up any part of your personal encryption method in a computer during or after creation of it all keys must be destroyed. You must rely on help of paper notes during development of your method and on your memory alone. You should never leave around any traces of the keys and the systematization used in your encoding method.
That’s an obvious one you may guess, but there are still people out there thinking they can trust their computers – do not, that I can assure you. If you do need to write something down for visualization, before you learn to do it in your mind, then you must destroy the paper each time you stop working on the code. To work on the code the next time you will write it all down from memory and will continue (that’s an excellent training by the way). You can storage ready scripts (cipher texts) in computer with no worries, but never together with the plaintext related to the script as it may significantly weaken your code making it vulnerable for further attacks.
Create your cryptic symbols different from any known to you symbols (not borrowed from any language), with several layers where the separate parts are difficult to distinguish and not easily understood by others, so that they’re not possible to input into a computer program automatically.
Your cryptic symbols must be complex enough requiring human work on each symbol trying to take it apart. If you create single layer symbols, with each corresponding to one actual symbol, then a scanned document can easily be translated into a computer language and a program can figure out the actual symbols by the frequency analysis.. and to crack the code in no time.
Always test your every newly created encryption method with a reasonable amount of cipher text, storing some complex, difficult to remember data which you can verify later. After you have forgotten the complex data sets, successfully deciphered the code and verified against errors, only then you can begin encrypting important data which you can’t afford to lose.
The length of the cipher text for trial depends on the complexity of the code — it should include all of the essential elements of your code several times, to make sure you won’t be confused yourself while deciphering the test data. The plaintext used for testing must not be kept anywhere together with cipher text or separately — the plaintext for testing must be a part of a larger volume of text/data but the location of the part used for testing must be only for you to know, never highlighted within the volume.
Read again the first rule of the basic principles of handwriting encryption. If you’re a very social person and like to share things then for social needs you can create a code for fun which you never use for encrypting important data. Your own personal code shall remain the murkiest mystery for others.
Cryptography is fun, and fun is always better when it is shared with others, thus creating a simple code just for fun is a reasonable thing to do.