This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
LDDestroier's profile picture

Enchat v2.3 - Encrypted, decentralized, color-formatted chat

Started by LDDestroier, 04 December 2015 - 02:00 AM
LDDestroier #1
Posted 04 December 2015 - 03:00 AM
Uses SquidDev's implementation of AES. Thanks heaps!
Obsoleted by Enchat 3. Go there instead.

Enchatv2.3

Now with flavor!


Enchat is a simple-to-use encrypted, decentralized, and colorized chat program for computers (both normal and advanced.)
It has commands, and you can scroll through the chat log with the mouse wheel.
Color formatting is supported, with '&' for text and '~' for background. This is configurable.
While entering text, your message will automatically color-format as you type it. This is also configurable.

pastebin get JtgbWdV5 enchat2
std pb JtgbWdV5 enchat2

When you boot it up, enter an encryption key to use, then your name. Both can also be inputted as arguments, too. Make sure to make your name colorful!

Press PageUP or PageDOWN to scroll up or down 4 lines. This is, as are other things, configurable.

If you have Enchat 2.3 or later installed on a Neural Connector with the Overlay Glasses (and a wireless modem), then you can get notifications for messages in the topleft corner of the screen. It's even kerned properly, woah.

Syntax:

enchat2 [key] [name]

Command list:
Spoiler

'/help [command]'
Returns a list of all the commands. If [command], then gives a small description of the command.

'/update ["beta", "stable"]'
If running from shell: downloads Enchat from pastebin, replaces current program, then reruns.
If running from dofile: prompts for download path, then downloads from pastebin, and reruns.
If pastebin is inaccessible, or is whitelisted for some reason, or if Enchat is in a read-only directory (/rom), it will safely go back to the chat prompt rather than crashing.
If you give the argument "beta", will update from the beta URL. Don't do that, though.

'/cry'
Returns a list of all users in range using the same key as you.

'/heil <person>'
Heil someone. If an argument isn't given, it defaults to a random name.

'/me <text>'
Make a message in the format of <*> %yourname% %text%. Just like in regular minecraft!

'/clear'
Clears your inventory. Just kidding. It actually steals your girlfriend.

'/ping [text]'
Pong!

'/whoami'
Tells you your current nickname.

'/colors'
Lists all color codes for use in text formatting. Use '&amp;' to change text color, and '~' to change background color.

'/nick <newname>'
Changes your nickname. You can even use color formatting in your name! Maximum 20 characters, after formatting.

'/palate <element> <newColor>'
Change the color palate of various elements of the interface. Currently, it's the following:
text, chattxt, bg, chatbg

'/set [configOption] [newValue]'
Change a config option for the current session, such as the scroll distance of the Page keys, whether or not text is colorized, whether to reverse scrolling direction, etc.

'/exit'
Closes out of Enchat cleanly.

Screenshot(s):
Spoiler
Colorful names and messages, and all encrypted with AES! (apparently it's "don't have a cow, man" but whatever)


Up to *that* many commands, and more since version 2.2!


List all colors for a quick reference!


Make very colorful messages (fancyMsg = true by default, but here it's false)


Format colorful dialogue as it's being typed! No other chat program does this to my knowledge! Which arguably isn't saying much


With the power of Plethora's Overlay Glasses, you can get screen notifications for messages in Enchat! They last 10 seconds onscreen by default, and can be disabled with the /set command.

You can get this with SuperTextDownloader! Contract it here!

Enchat requires ComputerCraft 1.6 (Minecraft 1.6.4) or later. I have yet to thoroughly test it, but based on when each function was added according to the CC wiki, you should be fine.
Edited on 21 October 2018 - 04:02 PM
Creator #2
Posted 04 December 2015 - 09:29 AM
Enchat is an Enchanting program.

Ontopic: Pretty nice.
HPWebcamAble #3
Posted 26 December 2015 - 05:50 AM
What happens if a third computer directs a gibberish message at one of the two chat computers?

Does the program crash? Does it show the message as more gibberish? Or does it do nothing (will be impressed if so ;)/> )?


I'd test it myself but I currently only have my poor laptop with me
LDDestroier #4
Posted 26 December 2015 - 06:01 AM
What happens if a third computer directs a gibberish message at one of the two chat computers?

Does the program crash? Does it show the message as more gibberish? Or does it do nothing (will be impressed if so ;)/> )?


I'd test it myself but I currently only have my poor laptop with me

It is possible to test rednet thingies using CCEmuRedux…if you go into the config and look up what to change to add a simulated modem.

The likelyhood of a computer redirecting gibberish at another is…more likely than I first thought. But what can I do with 2^16 channels? If one computer reads gibberish from another channel, then it simply displays a gibberish name and gibberish message. A person can still suggest the use of another key in plain text.
I'm gonna go edit the program to try to eliminate that problem.
Anavrins #5
Posted 26 December 2015 - 06:26 AM
What happens if a third computer directs a gibberish message at one of the two chat computers?
Does the program crash? Does it show the message as more gibberish? Or does it do nothing (will be impressed if so ;)/> )?
A quick and dirty way of preventing this would be to append every message with some sort of header before encryption, and only print a message if that header is found after decryption.
HPWebcamAble #6
Posted 26 December 2015 - 06:21 PM
What happens if a third computer directs a gibberish message at one of the two chat computers?
Does the program crash? Does it show the message as more gibberish? Or does it do nothing (will be impressed if so ;)/> )?
A quick and dirty way of preventing this would be to append every message with some sort of header before encryption, and only print a message if that header is found after decryption.

I try to avoid a common string in multiple messages, isn't that how Allen Turing broke the German encryption?
Sure, you need to know what the common thing is before you can decrypt the message. And that wouldn't be hard to prevent by using a complicated header (it would probably include the password itself, or an encrypted variation)

A strange system I thought of was encrypting the password with itself, then sending it with the encrypted message. Every time a computer sends a message to the other computer, it encrypts the already-encrypted password again.
That way, any computer listening in can't just resend the encrypted string to screw with either computer, as it would no longer be valid.
Wojbie #7
Posted 26 December 2015 - 07:00 PM
A strange system I thought of was encrypting the password with itself, then sending it with the encrypted message. Every time a computer sends a message to the other computer, it encrypts the already-encrypted password again.
That way, any computer listening in can't just resend the encrypted string to screw with either computer, as it would no longer be valid.
That would allow for reverse decryption over long communication. Because same string would get encrypted over and over again and send back and forth you would have a lot of samples before->after encryption just by listening to open communication.
Pyuu #8
Posted 26 December 2015 - 07:15 PM
I found an interesting "bug". Similar passwords can cause them to show up on some clients.
Try using passwords: helloworld , helloworl
Clients using helloworld can't see helloworl messages, but helloworl clients can see helloworld messages, resulting in a beautiful mess:
Spoiler
NilLogic #9
Posted 26 December 2015 - 07:20 PM
That bug.. I'm speechless. I just wanted to say what a cool program idea this is ;)/> May I suggest 3+ way communication?
Wojbie #10
Posted 26 December 2015 - 07:46 PM
I found an interesting "bug". Similar passwords can cause them to show up on some clients.
Try using passwords: helloworld , helloworl
Clients using helloworld can't see helloworl messages, but helloworl clients can see helloworld messages, resulting in a beautiful mess:
Spoiler

This is a known bug in valithor's "short little encryption API". That this program uses.
Edited on 26 December 2015 - 06:47 PM
Pyuu #11
Posted 26 December 2015 - 08:07 PM
-snippy-

This is a known bug in valithor's "short little encryption API". That this program uses.

Cool to know, but when reading through the code, it seems… very unlikely this should happen. Considering for a message to be visible it has to pass through a Checksum parameter (an essentially randomized string based on the key being encrypted.)
Wojbie #12
Posted 26 December 2015 - 08:14 PM
-snippy-

This is a known bug in valithor's "short little encryption API". That this program uses.

Cool to know, but when reading through the code, it seems… very unlikely this should happen. Considering for a message to be visible it has to pass through a Checksum parameter (an essentially randomized string based on the key being encrypted.)
Yes but Val all has a hash collision on last letter. So similar words with close last letter generate same hash = same decryption key. I have semi working brute force cracker working off this error. It allows to crack up to 8 letters sentences relativity fast. Over that barrier the time it takes makes it kinda unreliable.
Anavrins #13
Posted 26 December 2015 - 09:34 PM
I try to avoid a common string in multiple messages, isn't that how Allen Turing broke the German encryption?
You're talking about an encryption method that was build in the 1920. Modern cipher are constructed to be resilient to known-plaintext attacks.
Though there's no proof Vali's code is safe against those, if you want a small, real-world cipher that are proven to be safe, there's RC4, and ChaCha20 (shameless plug)
Edited on 26 December 2015 - 08:39 PM
LDDestroier #14
Posted 26 December 2015 - 09:52 PM
I…I just changed it to take the concatenation of the string.byte() of each character in the key, encrypt it with the key, then send it as a third data entry. I'm surprised I got this many comments so fast! (As I type there are 3 users on this post!)
HPWebcamAble #15
Posted 26 December 2015 - 09:59 PM
That would allow for reverse decryption over long communication. Because same string would get encrypted over and over again and send back and forth you would have a lot of samples before->after encryption just by listening to open communication.

True, guess its back to the drawing board for that idea


You're talking about an encryption method that was build in the 1920. Modern cipher are constructed to be resilient to known-plaintext attacks.
Though there's no proof Vali's code is safe against those, if you want a small, real-world cipher that are proven to be safe, there's RC4, and ChaCha20 (shameless plug)

The Enigma encryption WAS resilient to plain text attacks. Wasn't it?
The problem was the Germans would broadcast the same messages every day, which provided a starting point to figure out the settings used to encode it.
Anavrins #16
Posted 27 December 2015 - 12:28 AM
The problem was the Germans would broadcast the same messages every day, which provided a starting point to figure out the settings used to encode it.
There was two big weaknesses/error, one is that multiple message was sent with the same or closely similar rotor settings, the other was that a letter could not be enciphered into itself, causing an inbalance in the letter frequency distribution.
There was also patterns in the message, such as weather reports, and "Heil H….", which could be considered as some kind of known-plaintext.

But in the end, modern ciphers are designed that even if you partially know the plaintext, they should resist key recovery.
"Resist" as in, it's not impossible, but it must be improbable to do.
With enough known plaintext, in the orders of several gigabytes, then one could probably recover, say a RC4 key.
But with a small constant header, there's just not enough data to recover any information about the key.
HPWebcamAble #17
Posted 27 December 2015 - 01:34 AM
The problem was the Germans would broadcast the same messages every day, which provided a starting point to figure out the settings used to encode it.
a letter could not be enciphered into itself…
There was also patterns in the message…

But in the end…with a small constant header, there's just not enough data to recover any information about the key.

I just remembered an episode of Numberphile where they talk about both of these flaws in detail. Its actually really intriguing

Anyways, I'd like to think there are no super hackers who play minecraft hacking encrypted computercraft rednet messages ;)/>
So I suppose any encryption that is at least vaguely secure will do
Pyuu #18
Posted 27 December 2015 - 01:42 AM
-snippy-

I just remembered an episode of Numberphile where they talk about both of these flaws in detail. Its actually really intriguing

Anyways, I'd like to think there are no super hackers who play minecraft hacking encrypted computercraft rednet messages ;)/>
So I suppose any encryption that is at least vaguely secure will do

I'd at least hope people don't discuss their legitimate passwords using this chat, just in the off-chance there might be someone waiting to snipe some people who are overly trusting of online communication systems.
PixelToast #19
Posted 29 December 2015 - 07:28 AM
I would reconcider using valithor's encryption library, its based heavily on math.random as a PRNG which uses java's extremely insecure and predictable java.util.Random
also it is prone to known plaintext attacks
in fact I might start writing an OpenCL kernel to crack it..
LDDestroier #20
Posted 31 December 2015 - 01:15 AM
I would reconcider using valithor's encryption library, its based heavily on math.random as a PRNG which uses java's extremely insecure and predictable java.util.Random
also it is prone to known plaintext attacks
in fact I might start writing an OpenCL kernel to crack it..

What API do you suggest?
HPWebcamAble #21
Posted 31 December 2015 - 04:38 AM
What API do you suggest?

I would suggest Squid Dev's AES API: http://www.computercraft.info/forums2/index.php?/topic/18930-aes-encryption/

I've never had any speed issues with it (despite what I've heard), and since you are only encrypting small sentences at a time I'm sure it'll be fine.
Anavrins #22
Posted 31 December 2015 - 07:45 AM
What API do you suggest?
I'm gonna go ahead and shamelessly plug my new chacha20 api http://www.computercraft.info/forums2/index.php?/topic/25474-chacha20-cipher-in-computercraft/
Simply another option which is more lightweight and slightly faster than AES, for the same amount of security, if not more.
Edited on 31 December 2015 - 07:33 AM
LDDestroier #23
Posted 01 January 2016 - 04:36 AM
I tried to use the AES api, and…it doesn't receive messages anymore. I'm sick of looking through it, can someone else look it over?

[HTML]Why didn't I just go to ask-a-pro to begin with? Mannnn.[/HTML]
Edited on 17 June 2018 - 05:36 AM
LDDestroier #24
Posted 04 January 2016 - 02:02 AM
Bump. I am seriously confused with this. Everything seems to be coded correctly, and the receiving clients should be receiving messages, but they don't. Would it have to do with using unicode characters?
HPWebcamAble #25
Posted 04 January 2016 - 03:35 AM
Bump. I am seriously confused with this. Everything seems to be coded correctly, and the receiving clients should be receiving messages, but they don't. Would it have to do with using unicode characters?

Wanna post your code in Ask a Pro?

It'll get more attention there
Also, I don't know about anyone else but I'm not implementing the API in your existing code. Wayyy to lazy for that. I will look at what you have though.
Anavrins #26
Posted 04 January 2016 - 09:23 PM
Bump. I am seriously confused with this. Everything seems to be coded correctly, and the receiving clients should be receiving messages, but they don't. Would it have to do with using unicode characters?
Might be, it will likely not work if you're not using CC 1.76.
If you are using a version lower than that, try encoding the message into a table format.
Try with these modifications https://www.diffnow.com/?report=qe8gz
Edited on 04 January 2016 - 08:37 PM
Lego Stax #27
Posted 20 January 2016 - 01:22 AM
I'd help you out if you still need it.
LDDestroier #28
Posted 20 January 2016 - 11:20 AM
I'd help you out if you still need it.

I'd say this program is done for now.
LDDestroier #29
Posted 29 March 2016 - 02:35 PM
New update!

I added some much needed features, such as some actual scrolling, and a buffer to store previous messages. Also a /clear command,
LDDestroier #30
Posted 04 April 2016 - 09:01 PM
New update 2.0!
+Switched from valithor's encryption API to AES! Finally! I didn't notice a speed difference either way, so even better.
+Added chatlog scrolling
+Added more commands (/me, /cry, /heil can have an argument)

Because of the switched protocols, it won't work with the previous version of enchat. But, because checksums are added to the message, it won't interfere.
LDDestroier #31
Posted 27 May 2016 - 03:15 AM
I finally added the option to change the encryption key mid-session. And I added the /ping command! Yay!!!
LDDestroier #32
Posted 20 March 2017 - 01:31 PM
A cool, radical, fantastical update!

COLOR CODES! Now you can format messages and names with &amp; for text, and ~ for background colors!

Full change log:

+Added color code formatting
+Added /nick command - change your name mid-session
+Added /colors command - show all colors and their respective alphanumeric code
+Added small indicator to show whether or not chat will scroll as new messages are received
*Radically optimized the scrolling
*Localized all the functions and variables properly
If you are using a normal computer and receive a colored message, it will default to white unless it is a shade of gray.

It even wraps properly! It took me an entire day to get a good set of functions to properly wrap color-coded text.

Thanks to Incinerate for debugging that one crash that I couldn't for the life of me figure out the cause of.
Edited on 30 March 2017 - 05:33 PM
LDDestroier #33
Posted 31 March 2017 - 01:28 PM
Apparently, updating enchat made it crash if you received new messages, but now it doesn't. I added some new things to the above changelog yesterday, but now would be a good time to go over the recent changes in a new post.
EDIT: I added more thingies since then. Many new, good things!

+Added new command -- '/palate'! Change the color palate to Enchat!
 Syntax: "/palate bg/txt/chatbg/chattxt <colorcode>" or "/palate reset"
+Added small "." indicator at bottom-right corner of screen to determine if the screen will scroll if new messages are received
+Added new color codes! "&amp;{" will disable all text/background formatting until you type in "&amp;}".
*Fixed the slow-as-balls scrolling
	(The slow scrolling was due to some boneheaded decision I made to encrypt the internal log table, then decrypt it upon redrawing the
	screen. What an idiot I was! I fixed that right up.)
*Fixed /update command
	(When you updated before, it would rerun the program from inside a function currently being ran under parallel.waitForAny(), along with
	some other functions for input and receiving messages. Rerunning the program at that point would also rerun extra instances of those other
	functions, and that is...NO GOOD.)
*Fixed ~r or &amp;r both resetting BOTH text and background
*Removed 'no space' limit of /nick, and replaced with 20 character limit (excludes formatting codes)
*Added argument to /update to update to beta. "/update beta"
*When rerunning after update, if your name has a space, it will no longer use the first word only.
*Changed /key output. Now, the key has quotes around it, and it doesn't colorize. (shows all formatting codes)

I dunno about you, but I'm happy with myself. Even if I'm only updating Enchat with these cool new features for two reasons, one being to appease myself, and one to bump the topic in hope of a glowing review to boost my egg-shaped ego.
Edited on 31 March 2017 - 04:25 PM
LDDestroier #34
Posted 06 April 2017 - 10:52 PM
okey good update yay

+Replicated functions added in CC 1.7 to allow compatibilty with ComputerCraft 1.6!
+Added new formatting code: "&amp;k" and "~k"!!
Do "&amp;k" to enable text obfuscation (krazy font), and "~k" to disable it.

Font Obfuscation requires redrawing the screen ten times a second (approx), so just be wary. However, it only redraws the screen if there is obfuscated text ON THE SCREEN, so okay.
If you obfuscate a narrow character (say, "l") then it will be krAAAAzy with l and 1 and | and whatnot. Same with "W" or "M" or other wide characters.
Otherwise, it takes a random character from 1 to 255. If your computer cannot handle rendering special characters, it will filter those out.
augiteSoul #35
Posted 17 April 2017 - 10:00 AM
When I try to use it in the latest 1.7.10 version of CC:
enchat:1122: attempt to index ? (a nil value)
LDDestroier #36
Posted 17 April 2017 - 10:23 PM
It should be fixed. Redownload and try again. I forgot that the internal settings table was called enchatSettings, not 'enchat'.
LDDestroier #37
Posted 27 April 2017 - 05:45 AM
New version update 2.2!

With this new version, I'm mostly incrementing the version number up by 0.1 as I have accreted more and more features and fixes into Enchat.
To be brief, here's all the wonderful things I've done that I can remember:

I added a new command – '/set': This command is used to change some config options stored in the table 'enchatSettings'. Just do '/set' to get the full list.
I fixed up doColorize = false: Apparently, having enchatSettings.doColorize = false made the screen freak out, so now that's all taken care of.
I added obfuscated text: In minecraft chat, you can use &amp;k to obfuscate your text and make it all wacky. In enchat, you can do that too! I had to optimize the renderer a lot, though. I've mentioned this before.
I combined all event-grabbing functions: I should've done that long ago. Having three functions that run in parallel and just grab events is messy.
I allowed pageUP and pageDOWN to be used for scrolling so that normal computers can better use Enchat. I could've sworn I'd added that before, oh well
I localized all drawing function so that rendering goes a lot smoother. I also use term.current().setVisible, but I've been doing that for a while now.

These changes might be trivial, but they do take a bit of work and a lot of testing to work well.

Let me know if there are any issues or flaws that you encounter through a comment or PM!
Edited on 27 April 2017 - 10:42 AM
LDDestroier #38
Posted 17 June 2018 - 07:22 AM
Since I laid eyes upon ore3d, I've come to the shocking conclusion that overlay glasses are rad. So I've added an update for Enchat 2.3 that shows notifications in the topleft corner of the screen if you install it onto a Neural Connector with a wireless modem and set of overlay glasses installed! Colored text and background colors work as they do onscreen, and the text is even kerned properly, man.

Here's the new screenshot that demonstrates it:
Spoiler

EDIT: Proper text wrapping has been added.
Edited on 17 June 2018 - 08:56 PM