Upstream/SubServers-2
1
0
Fork 0
mirror of https://github.com/ME1312/SubServers-2.git synced 2025-02-17 20:21:33 +01:00
Code Issues Projects Releases Wiki Activity

Updated SubData (markdown)

ME1312 2020-03-02 23:07:01 -05:00
parent 7497c188ff
commit 051da430e9
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
SubData.md

@ -39,4 +39,11 @@ For some java installations, AES 192 and/or 256 bit encryption has been disabled
<br>
So, what's better than some good ol' password-based encryption? How about a system where we login using a signature file, send over a completely randomized password that was encrypted using that signature, and then start encrypting using that randomized password. Yeah, sounds better to me, too.
In this mode, each SubData connection uses it's own randomized password to AES encrypt and decrypt data after login. Even though you may be sending the same data, no two connections are the same.<br>
In this mode, each SubData connection uses it's own randomized password to AES encrypt and decrypt data after login. Even though you may be sending the same data, no two connections are the same. This can be considered the most secure mode of SubData.<br>
### DHE + AES
`Encryption`: `DHE/AES`, `DHE-128/AES-128`, `DHE-192/AES-192`, `DHE-256/AES-256`<br>
<br>
If you don't feel like fumbling around with passwords and key files just to get some encryption, then this one's for you. By using the Diffie-Hellman Exchange, both ends of the connection can agree on a completely randomized password to encrypt with automatically.
As you may have noticed, this mode is similar in nature to `RSA/AES`. The main difference is the lack of key files. What you're giving up on for this ease of use, however, is the simple fact that only *you* have *your* key files. Being keyless, the Diffie-Hellman Exchange doesn't care who's on the other end when negotiating a password.<br>