diff --git a/SubData.md b/SubData.md
index dd94f57..262d395 100644
--- a/SubData.md
+++ b/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>
\ No newline at end of file
+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>
\ No newline at end of file