0

Note that this question describe hypothetical case, that is never meant to be used in real world.

Server communicates with clients with message structure: client_id, initialization_vector, encrypted body. Each client each day exchange with server 1-5KB messages average 100 times. Messages "occasionally" may leak out, due to insecure network (e.g. DNS spoofing).

Generated keys are distributed securely to clients by another system. When a key gets compromised, the client can issue another one, but currently the key has no expire time (even after few years). I want to avoid mixing RSA and other asymmetric stuff to keep this simple. Message protocol may change in the future, but previously issued key will be used for stronger encryption without requiring re-issue.

Is this kind of system secure when used with e.g AES/CBC + padding? Can I firmly go forward with this basic approach for years?

Edit 1:

Message initialization_vector is random (AES/CBC) at each message and encrypted_body has internal (encrypted with body) integrity checks (MAC and digest). What makes it insecure despite that? Is option to compromise AES encryption over time really viable in that case?

Edit 2:

Here is pseudo-code of message encryption. When message MAC is not valid, error response is not encrypted (to avoid active attack). System will drop old messages when timestamp is older than T (to avoid reply attack).

init_vector := secure_random (); // for AES/CBC or increment init_vector for AES/CTR
mac = hash (client_id + timestamp + init_vector + text); // MD5 or SHA-1
body = encrypt (mac + text); // AES/CBC
message = client_id + timestamp + init_vector + body;
  • What is a private key in a symmetric key encryption system? It sounds like you are rolling your own encryption scheme. – Aron Jun 19 '15 at 09:03
  • @Aron I changed title to more clear. Generally it is about AES key in long run. –  Jun 19 '15 at 17:35
  • @jlmfao: As I mentioned in my comment under my answer, a lot depends on exactly how the internal integrity checks work. –  Jun 19 '15 at 18:37
  • @RickyDemer I added integrity check description - hope that's what you mean. –  Jun 19 '15 at 19:32
  • Well, I can't immediately figure out how to break that (even though your "MAC" is not actually a MAC). –  Jun 19 '15 at 20:04
  • On the other hand, with AES/CTR, your scheme would definitely be malleable, even if you stuck with secure_random for that mode. –  Jun 19 '15 at 20:19
  • I should definitely start a new question, with more specific case and real code - this one have leaves too much unsaid. Thanks. –  Jun 19 '15 at 21:54

1 Answers1

1

No, although the reason I see is independent of most of your post.
CBC mode is malleable; you should use a MAC too.

Community
  • 1
  • Even if initialization_vector is random (AES/CBC) at each message and encrypted_body has internal integrity checks (MAC and digest)? What makes it insecure despite that? –  Jun 19 '15 at 05:31
  • It depends on exactly how the internal integrity checks work. –  Jun 19 '15 at 06:29