A suite of encryption routines in a self contained HTML file that can be used ith Instant Messaging programs, such as Twitter, Facebook Messanger, and even Reddit and the such.
The prime motivation for writing this is to demonstrate how futile attempting to pohibit use of encryption technologis through legislation is. It also though has more practical uses, including assisting in educating people regarding encryption. It can also be used for privacy and authentication where no other method is available.
The program itself is written using raw HTML, CSS and Javascript. Currently it makes use of Javascript's "Bigint" facility, which is specified in ECMA262. The HTML file is completely self contained. There are no links to any other files. It can be, and should be, downloaded to local disk or storage and run from there. It can even be run without a network connection.
This should be able to run on modern versions (or later) of:
Should requirement arise, I will put a pure javascript replacement routine in for the "Bigint" functionality, which would cater to much older browsers. Even without that this routine should be able to run on about 99% of the computers out there, incluing mobile devices.
The encryption technologies employed are:
All the program is contained in a single HTML file. To run it, it is best to download it to a your "Downloads" directory and load and run the HTML file there by opening it in your browser. The program is at https://edlsystems.com/imcrypt/imcrypt.html:
At time of writing, on Android phones it is hard to load and run HTML/Javascript from local storage using Chrome or the Android WebViewer, it is a lot easier to do so running Firefox. I do not know about iPhones/iPads and iOS.
Shared secrets, or technically speaking "Synchronous Encryption", relies on a shared scret between parties. If you know the "secret", you can decipher messages in the conversation and cipher your own.
In order for it to be effective, parties need to agree on a "secret" before hand, or by a secure communication.
The procedure would be:
Public keys, or "Asynchronous Encryption", does not require prior secrets. Instead it uses mathematics to perform the excusivity needed.
Each participant creates a "key pair" by running a routine that produces:
In order for, for example, Alice to communicate with Bob privately, Alice will encrypt a message using her private key and Bob's public one. This then can be decrypted by Bog using his private key and Alice's public one. At not time is it neccessary for Alice to give Bob her private key, or Bob to give Alice his.
The procedure for this is:
An advantage of this type of encryption is that the keys can be exchanged over an insecure medium, so long as the recipient can verify somehow the keys have not been altered in communications, and actually originate from the person involved rather than an imposter.
Signatures use the Private/Public key mechanism to enable a person to "sign" a message or a file, and for others to "validate" that signature with the original message or file, and to ensure it has not been altered.
The procedure for this would be:
It is worth noting that if Alice encrypts the purchase order, she would not need to "sign" it, because when Bob decrypts it he would need Alice's public key validating the order came from her.
The IM Crypt HTML file contains self contained programs designed to be transmitted using Instant Messaging / Social Media platforms such as Twitter and similar. The overall concept is that this page generates public keys, encrypted messages, signatures and the such that can them be copied and pasted into Instant Messaging clients and transmitted. The receiver can then copy the messages and pasted into his/her copy of the IM Crypt HTML page to be registered, decryptted and/or verified etc.
The IM Crypt HTML routines do not store any information on disk, nor does it use any "HTMLRequest" calls to the server of any sort. It is in fact possible to download the "imcrypt.html" page to local storage and load and run it from there. In fact, this is the recomended method where feasable.
The user enters pass phrases and passwords which are used to generate keys and secrets, and these need to be entered each time the user loads the page as nothing is "saved" anywhwere. Private and secret keys generated are never displayed or transmitted, but "fingureprints" are displayed. These fingureprints are genertated in such a way that the private key or secret that generated cannot be derived from them. They are in hexadeximal format, four "batches" of a pair of four hexadecimal numbers. The purpose of these is to make it easier to identify and confirm secrets entered.
When loading the IM Crypt HTML page the user will be prompted to click the mouse/tap a message 30 times in an unpredictable way. This is to prime an "Entropy Pool" as IM Crypt HTML does not rely on internal libraries for such things. When this is done the user can click on "Continue to IM Crypt" button for the front screen...
The front screen consists of a number of options (currently just 2). To "go into" one of these cick on the appropriate button. The user can go back to the "Menu Screen" any time by pressing the <- button at the top left of the screen.
This is used for ad-hoc communications where a shared secret can be agreed beforehand using a secure means of communication. It also can be used can be used for "group" chats, where each member of the group knows the "secret". Secrets are entered into a "Secret Text" and "Secret Password" fields, then those are used to generate a secret key that is used for the encryption and decryption processes.
| Field | Description |
| Show Secret Fields Toggle Buttons | |
| Show Secrets | Toggle button to show the "Secret" fields |
| Hide Secrets | Toggle button to hide the "Secret" fields |
| Secret Fields Entry | |
| Secret Text | Text box to input some secret text. The default state of this is that the font color is the same as the background color. This is so someone looking over your shoulder cannot determine what is being entered. |
| Show | Checking this box sets the Secret Text's font and background color so it can be seen. |
| Secret Password | A string to accompany the above text. It is combined with the text when generating the secret key. |
| Show | Modifies the Secret Password's field type so the contents there can be seen. |
| Generate | Generate the secret key from the text and password. For this to work there needs to be something in the Secret Text field, the password is optional. |
| The publishable (Hashed) Secret Fingureprint | |
| Fingureprint | This is used to identify the secret key to others using the IM Crypt HTML routines without revealing what the secret text and/or password contents. Useful for confirming everyone has entered the secrets correctly. |
| Messages or Files Toggle Buttons | |
| Messages | Send and receive encrypted messages that are copied and pasted to the Instant Message client. |
| Files | Send and receive encrypted files that can be attached to some Instant Message client messages. |
| Messages: Input / Output / Encryption Fields | |
| Input | The text to encrypt or decrypt. |
| Mode List | For encryption: "Block" mode. See below for details. "CFB" is OK for this. |
| Compress | For encryption: When set the output consists of "Base Plane UTF" characters rather than Base64 characters. This means the encrypted message uses fewer text characters. |
| Encrypt | Encrypt the input data placing the encrypted message in the "Output" field. |
| Decrypt | The encrypted message has been pasted into the input field, this decrypts that and puts the original message in the "Output" field. It also sets the "Mode" and "Compress" fields to what was used to encrypt this. An error message appears if it cannot decrypt this. |
| Output | The output of the above. This is read only. |
| Files: Choose / Save / Encryption Fields | |
| Choose file | Select a file to encrypt or decrypt. The file needs to be "Loaded" prior to processing. |
| Mode List | Same as for "Messages". The "Compress" featrure is not applicable because the file is encrypted/decrypted as binary bytes rather than text characters. |
| Encrypt | |
| Decrypt | |
| Save | Save the encrypted/decrypted file. When encrypting a file the file name is a numeric representation of the time with an "imc" extension. The base name of the original file is stored witin the encrypted "imc" file and when decrypting it saves it using the original name. |
This is also known as "Asymetric Cryptography", here the user creates a "Key Pair" consisting of a "private" key and a "public" one.
They then publishes the "public" key to the world.
The "private" key is never shared with anyone. Nor is the secrets used to generate the pair. Not to anyone. Ever. Cryptography is achieved by using your own private key, other people's public key and mathematics.
| Field | Description |
| Show Secret Fields Toggle Buttons | |
| Show Secrets | Toggle button to show the "Secret" fields |
| Hide Secrets | Toggle button to hide the "Secret" fields |
| Secret Fields Entry | |
| Name/ID/Email | This is the users identity. It does not need to be "genuine", and is never transmitted. It is included in the secrets to decrease the chance of duplicate keys existing because two people think of the same secrets. |
| Secret Text | Text box to input some text, such as a list, or a poem verse. The default state of this is that the font color is the same as the background color. This is so someone looking over your shoulder cannot determine what is being entered. |
| Show | Checking this box sets the text's font and background color so it can be seen. |
| Secret Password | A string to accompany the above text. It is combined with the text when generating the key pair. |
| Show | Modifies the password's field type so the contents there can be seen. |
| Generate | Generate the key pair from the ID, text and password. For this to work there needs to be something in the ID field. |
| Private Key status, Public Key and it's fingureprint | |
| Status | The status of the private key. The private key itself is never displayed or transmitted. |
| Public Key | The public key others will use for this feature. You can copy and paste this to the IM Client(s) to transmit to others. |
| Fingureprint | This is used to identify the key pair to yourself and others using the IM Crypt HTML routines without revealing what the secret ID, text and/or password contents. Useful for confirming you have entered the secrets correctly, and is easier to "read" than the public key itself. |
Used for private conversation between yourself and someone else (your partner). For this you will need your own private key and your partner's public one. Your partner will need their private key and your public one.
| Field | Description |
| Private Key status, Partner's public Key and it's fingureprint | |
| Status | The status of your private key. The private key itself is never displayed or transmitted. |
| Public Key | Paste your partner's public key into this field. |
| Fingureprint | Fingureprint of your partner's public key, useful for verifying it is pasted/entered correctly and the correct one. |
| Messages or Files Toggle Buttons | |
| Messages | Send and receive encrypted messages that are copied and pasted to the Instant Message client. |
| Files | Send and receive encrypted files that can be attached to some Instant Message client messages. |
| Messages: Input / Output / Encryption Fields | |
| Input | The text to encrypt or decrypt. |
| Mode List | For encryption: "Block" mode. See below for details. "CFB" is OK for this. |
| Compress | For encryption: When set the output consists of "Base Plane UTF" characters rather than Base64 characters. This means the encrypted message uses fewer text characters. |
| Encrypt | Encrypt the input data placing the encrypted message in the "Output" field. |
| Decrypt | The encrypted message has been pasted into the input field, this decrypts that and puts the original message in the "Output" field. It also sets the "Mode" and "Compress" fields to what was used to encrypt this. An error message appears if it cannot decrypt this. |
| Output | The output of the above. This is read only. |
| Files: Choose / Save / Encryption Fields | |
| Choose file | Select a file to encrypt or decrypt. The file needs to be "Loaded" prior to processing. |
| Mode List | Same as for "Messages". The "Compress" featrure is not applicable because the file is encrypted/decrypted as binary bytes rather than text characters. |
| Encrypt | |
| Decrypt | |
| Save | Save the encrypted/decrypted file. When encrypting a file the file name is a numeric representation of the time with an "imc" extension. The base name of the original file is stored witin the encrypted "imc" file and when decrypting it saves it using the original name. |
This is used for you to certify contents of a file or message by "sign"ing it. You can then copy and paste the signature into an Instant Messaging client to transmit it.
| Field | Description |
| Private Key status | |
| Status | The status of your private key. The private key itself is never displayed or transmitted. |
| Messages or Files Toggle Buttons | |
| Messages | Sign a message. |
| Files | Sign a file. |
| Messages: Signing | |
| Input | The text to sign. |
| Sign | Sign the message and place the resulting signature in the "Signature" field. |
| Signature | The resulting signature. This is read only. |
| Files: Signong | |
| Choose file | Select a file to sign. The file needs to be "Loaded" prior to processing. |
| Sign | Sign the contents of the file and place the resulting signature in the "Signature" field. |
| Signature | The resulting signature. This is read only. |
This verifies a signature created by someone else (the sender). This is done by performing a calculation on the sender's public key, the data that was signed and the signature.
| Field | Description |
| Public Key and it's fingureprint | |
| Public Key | Paste the sender's public key into this field. |
| Fingureprint | Fingureprint of the sender's public key, useful for verifying it is pasted/entered correctly and the correct one. |
| Messages or Files Toggle Buttons | |
| Messages | Verify a message. |
| Files | Verify a file. |
| Messages: Verifying signature | |
| Input | The text to verify. |
| Signature | Paste the signature the sender created for the message here. |
| Verify | Verify the message and show the result. |
| Files: Verifying signature | |
| Choose file | Select a file to verify. The file needs to be "Loaded" prior to processing. |
| Signature | Paste the signature the sender created for the file here. |
| Verify | Verify the message and display the result. |
One of the following will be displayed next to the "Verify" button:
Encryption and decription is initially done with a "base" key, being the secret key derived from the "Secret" fields, or the combined key calulated from your Provate Key and ypur partners Public one. However this is used to cipher the header block, which originally contains header meta information (first 2 bytes) - being the IM Crypt HTML version and which "Mode" was used. The remaining 14 bytesbneing random data. This (deciphered) is then hashed with the "base" key to produce a "working" key for the rest of the message or file.
The header (cipered) is also used as the Inintailization Vector for the first block.
Block ciphers dictate how the AES cipher is applied to the data to encrypt and decrypt it. For IM Crypt HTML it practically does not really matter which one is used, but I coded different ones and there is a choice any.
AES ciphers in 16 bytes (128 bits) blocks.
All modes have a 16 bytes prepended to the encrypted data which acts as an Initialization Vector (IV) to the first block.
| Mode | Description | Encryption details. Decrypting is the reverse |
| OFB | Outbook Feed Back. | IV -> Cipher -> Copy saved for next block's IV -> BIT-ORed with input -> output |
| CFB | Cipher Feed Back. | IV -> Cipher -> BIT-ORed with input -> output and next block's IV |
| CTR | Counter. | IV -> BIT-ORed with the block number -> Cipher -> BIT-ORed with input -> output |
| CBC | Cipher Block Chaining. | IV -> BIT-ORed with input -> Cipher -> output and next block's IV |
| PCBC | Persistent Cipher Block Chaining. | IV -> BIT-ORed with input -> Cipher -> output -> BIT-ORed with input -> Next block's IV |
| BCTR | Book Counter. | IV -> BIT-ORed with the block number -> BIT-ORed with input -> Cipher -> output |
The "OFB", "CFB" and "CTR" are stream based modes. That is, in effect, the cipher is used to generated a predictable random number based on the key and data, which is "BIT-ORed" with the input to produce the output. That means that the "Cipher" routine is used on decryption as well as encryption (as opposed to the "Deciphering" routine). Also partial blocks at the end of the message are easily handled as each byte in the data (after the initial 16) corresponds to the appropriate byte in the output.
The "CBC", "PCBC" and "BCTR" modes are block based modes. That is encryption is achieved by ciphering the input after it is "BIT-ORed" with an initialisation vector based on previous data. The decryption procedure needs to use a "decipher" algorythm rather than the original "cipher" one, Also, this makes partial blocks at the end of the message more complex. If the original data is less than 16 bytes long then it is padded out with "Zeroes" (Byte value 0x00) to be 16 bytes in length. If more a process of "Block Stealing" is used on the penultimate block to handle partial ones at the end.
The signatures used in IM Crypt HTML "Sign with Privare Key" functionality uses ECDSA. For this to work a secret non-guessable 256 bit number meeds to be generated, known usually as k. It is important that the same k is not used for different messages for the same key. For most cryptography programs k is generated using random numbers extracted from an entropy pool. However this generates different signatures if the same "key" signs the same message more than once. This I felt was non-intuitive to the audience IM Crypt HTML utilities was aimed at, so in this k is generated using a ciphered value, using the private key as the cipher key, with the hash of the message as the input. This is ciphered repeatedly if more than one "go" is required to get k. This means k is non-guessable and is not re-used for different messages so therefore secure, but does not change if a user signs the same message twice.