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 '&' 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 by LDDestroier, 21 October 2018 - 05:02 PM.
HPWebcamAble, on 26 December 2015 - 05:50 AM, said:
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.
LDDestroier, on 26 December 2015 - 06:01 AM, said:
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.
LDDestroier, on 26 December 2015 - 06:01 AM, said:
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.
HPWebcamAble, on 26 December 2015 - 06:21 PM, said:
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.
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:
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:
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.)
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.
HPWebcamAble, on 26 December 2015 - 06:21 PM, said:
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)
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!)
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
Anavrins, on 26 December 2015 - 09:34 PM, said:
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.
HPWebcamAble, on 26 December 2015 - 09:59 PM, said:
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.
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
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.
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..
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..