AES should never be used in ECB mode about ejtp-lib-python HOT 3 OPEN

AES has always been one of the worst encryption options available in EJTP, because there is no good fit in terms of cipher algorithm. The reason is that the EJTP frame model is extremely stateless. Frames can arrive in any order, at any time, and under bad network conditions some frames will drop. It's like encrypted UDP. You can use EJForward to handle retransmission, but you still have the order problem, and the fact that we don't track cipher stream state for anything.

Every frame is distinctly encrypted and has to be able to stand alone.

This is a bitch for getting stream encryption advantages, but I don't think it's impossible. There should theoretically be some efficient way to include ephemeral IV data at the head of every encrypted string. If you have any advice on how we would do this, given the constraints of the frame model's UDP-like nature, please let me know. It's something that's kind of been sitting stagnant, waiting for someone to come along who knows what he's doing.

from ejtp-lib-python.

Well, the usual method is this:

1. Generate a random IV for each message from os.urandom()
2. Encrypt the plaintext with the encryption key and IV in CBC mode.
3. Append a timestamp and the IV to the ciphertext. (You can check this timestamp later to mitigate replay attacks.)
4. Compute the HMAC of the ciphertext, IV, and timestamp with the hashing key.
5. Append the HMAC to the message. Send it out!
6. When the receiver gets the message, it first checks the HMAC, then the timestamp, then decrypts the message, then parses the JSON. Be sure to use a constant-time string comparison for the HMAC check.

The alternate method, which I would highly recommend, is to use PyNaCl. It does everything I just said, but better, and the API is super-easy.

from ejtp-lib-python.

Thank you very much for the rundown! It looks like PyNaCl is somewhat picky about what algorithms are currently available, so no AES, but this doesn't seem too onerous to do manually, especially thanks to the hmac module (which is arguably the most complex part of the dance).

The only part that worries me, of course, is timestamp persistence. Where that data is stored, how long, etc. On its own, EJTP intentionally only uses volatile memory (RAM), except to load identity data from cache files (which are not good candidates for storing hundreds or thousands of timestamps per identity). If we can solve that issue, we can finally move forward and make AES worth using.

from ejtp-lib-python.