Jump to content




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


37 replies to this topic

#1 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

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

Screenshot(s):
Spoiler

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.


#2 Creator

    Mad Dash Victor

  • Members
  • 2,168 posts
  • LocationYou will never find me, muhahahahahaha

Posted 04 December 2015 - 09:29 AM

Enchat is an Enchanting program.

Ontopic: Pretty nice.

#3 HPWebcamAble

  • Members
  • 933 posts
  • LocationWeb Development

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

#4 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 26 December 2015 - 06:01 AM

 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.

#5 Anavrins

  • Members
  • 775 posts

Posted 26 December 2015 - 06:26 AM

 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.

#6 HPWebcamAble

  • Members
  • 933 posts
  • LocationWeb Development

Posted 26 December 2015 - 06:21 PM

 Anavrins, on 26 December 2015 - 06:26 AM, said:

 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.

#7 Wojbie

  • Members
  • 631 posts
  • LocationKinda lost

Posted 26 December 2015 - 07:00 PM

 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.

#8 Pyuu

  • Members
  • 203 posts

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


#9 NilLogic

  • Members
  • 45 posts

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?

#10 Wojbie

  • Members
  • 631 posts
  • LocationKinda lost

Posted 26 December 2015 - 07:46 PM

 Mayushii, on 26 December 2015 - 07:15 PM, said:

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 by Wojbie, 26 December 2015 - 07:47 PM.


#11 Pyuu

  • Members
  • 203 posts

Posted 26 December 2015 - 08:07 PM

 Wojbie, on 26 December 2015 - 07:46 PM, said:

-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.)

#12 Wojbie

  • Members
  • 631 posts
  • LocationKinda lost

Posted 26 December 2015 - 08:14 PM

 Mayushii, on 26 December 2015 - 08:07 PM, said:

 Wojbie, on 26 December 2015 - 07:46 PM, said:

-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.

#13 Anavrins

  • Members
  • 775 posts

Posted 26 December 2015 - 09:34 PM

 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)

Edited by Anavrins, 26 December 2015 - 09:39 PM.


#14 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

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!)

#15 HPWebcamAble

  • Members
  • 933 posts
  • LocationWeb Development

Posted 26 December 2015 - 09:59 PM

 Wojbie, on 26 December 2015 - 07:00 PM, said:

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.

#16 Anavrins

  • Members
  • 775 posts

Posted 27 December 2015 - 12:28 AM

 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.

#17 HPWebcamAble

  • Members
  • 933 posts
  • LocationWeb Development

Posted 27 December 2015 - 01:34 AM

 Anavrins, on 27 December 2015 - 12:28 AM, said:

 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.
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

#18 Pyuu

  • Members
  • 203 posts

Posted 27 December 2015 - 01:42 AM

 HPWebcamAble, on 27 December 2015 - 01:34 AM, said:

-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.

#19 PixelToast

  • Signature Abuser
  • 2,265 posts
  • Location3232235883

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..

#20 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 31 December 2015 - 01:15 AM

 PixelToast, on 29 December 2015 - 07:28 AM, said:

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?





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users