0

I'm writing a small protocol that relies on a DH handshake, generation of a shared secret, and subsequent AES encryption/decryption using that generated secret. I want to add a built-in test message after the handshake to ensure both clients are able to communicate properly (in addition to a CRC). Is building a small "TEST123" -encrypt-> ciphertext -decrypt-> "TEST123" into the protocol a security vulnerability, since someone now knows the ciphertext for some given plaintext?

jpalm
  • 101
  • 1

1 Answers1

1

Designing your own protocol for something secure is generally a bad idea. Don't roll your own.

It's probably not a significant weakness. It does expose yourself to a known-plaintext attack, but luckily AES is secure against known-plaintext attacks.

Granted, using a CRC to test that communication is working properly is not a good idea (unless this is only done at a network layer on the sent ciphertext), as CRCs aren't cryptographically secure. You really should use a keyed-MAC to prevent tampering (and sequence numbers/timestamps to prevent replay attacks).

Community
  • 1
dr jimbob
  • 38,936
  • 8
  • 92
  • 162
  • All of the crypto is handled by OpenSSL. This is more of a proof-of-concept, I'm building it on top of the Android NFC ISO-DEP protocol and I'm really just facilitating the handshake, generating the cipher, and letting the devices communicating using their shared key. – jpalm Jul 22 '14 at 17:09