Easy to use program to encrypt/decrypt messages and files (files are WIP).
Configure a key on the right.
Then write text into the upper text-field and press "Execute", or Ctrl + Enter.
The encrypted text is shown on the bottom.
Plain old password.
MessageCrypt has no restrictions to your password, you can even leave it empty. However, longer passwords are immensly more secure than short ones.
Below the password-field is a tool to calculate how long it could take to break a password. Test it, you'll probably never set a short password ever again.
But how to get a password (or key) to your communication-partner?
Sending it to them is very insecure.
That's why you can perform a Diffie-Hellman key-exchange.
You and your partner send each other one software-generated text. From these texts, you and your partner can each generate the same password.
Even if the two messages were public, noone could generate the password except for you two.
For text that isn't ment for communication, I recommend generating a random key.
The generated key is 32 bytes long, which equals about 43 characters of password-length. That's the maximum security AES-256 provides.
Below the key-section, you'll find the key manager.
This is basically a password-protected file that can store and load your keys/passwords.
Make sure to use a very secure password for this.
Everything is encrypted in AES-256-GCM, with a 16 byte nonce and a 8 byte tag.
Key-derivation is done using argon2 algorithm.
Hashing is done with SHA-256.
The Diffie-Hellman key exchange is done using elliptic curve cryptography on an Ed25519 curve.
Every time a key is used for encrypting, that key is altered using a quick configuration of argon2. The salt is derived from the encryption-nonce.
To make passwords safer, an additional key-derivation is performed for passwords. That derivation also uses argon2, but is a lot safer (takes longer). That salt also derives from the nonce.
For the password of the key-manager, the key-derivation is even safer.
Nonce and tag are appended to the front of encrypted texts. That way, every encryption is unique.
AES-256-GCM is the current standard for symmetric encryption. There are no known weak-points other than testing literally every possible key until one fits. There are 10 to the power of 77 possible keys, so good luck with that. For a 1% chance of getting it right, you need to test 10 to the power of 75 keys.
The necessary key-length of AES-256 is 32 bytes, which translates to roughly 43 password-characters. Since noone would ever make such a long password, we use key-derivation (one of the reasons). The password isn't the actual key, the key is derived from the password.
However, someone might just try to guess the passowrd. There are far less (realistic) passwords than keys, right? Wouldn't this make passwords themselves insecure?
The trick is that key-derivation is done intentionally elaborate. Each derivation requires a lot of processing-time. So while trying a single password, you could try thousands of keys instead.
Still, a long password is essential!
Example: If a supercomputer needs one day to try every possible 7-character long password, with 8 characters, it takes 81 days. With 9 characters, it take 17.5 YEARS.
To create a shared key with someone else, you and your partner need to exchange a total of two messages.
What if someone reads those messages?
Don't they know the password too?
Well, no.
I'll explain why in a bit, but if you don't care, just know that the used key-exchange is also very secure. I didn't trust this system before understanding how it works, so let me explain.
These two messages are very big numbers calculated from random numbers in a specific way.
To explain how this works, let's define that b = 16. Everyone knows that b = 16, so everyone can calculate with it.
First, you and your partner generate two random numbers.
Let's say, r1 = 16 and r2 = 5.
Both of you add their random number to b:
b + r1 = 32
b + r2 = 21
The calculated numbers are what is being sent to the partner.
Then, the both of you add their own random number to the number they received:
r1 + 21 = 37
r2 + 32 = 37
As you can see, both have equal solutions. You can't know the solution only knowing what the two sent each other (32, 21), because you don't know r1 and r2.
But wait, couldn't I just calculate r1 = 32 - b?
You could, but only if "+" refered to an actual addition.
In reality, that "+" is a very complicated operation you can't "turn around".
Also, the numbers don't only have two digits, but up to 77.