Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am designing a system that uses TLS-like handshaking on a resource-constrained embedded system. I have settled on AES-CCM mode for symmetric session encryption and authentication, allowing encryption and MAC to use the same key. I would further like to combine the server write and client write keys into a single key for both directions because I would like to avoid having 2 expanded keys stored for each open session.

Nonce non-reuse in this case is achieved through a combination of a per-device ID and an incrementing frame counter, but I can also add an extra bit to differentiate client versus server writes at the nonce level, ensuring non-reuse of a nonce/key combination between both halves of the conversation.

Can anyone foresee a specific possible problem with doing this?

(PS: I am aware of the normal reason for separate encryption keys for each direction, and for separate MAC/encryption keys for modes other than CCM and GCM. I am also most interested in specific possible problems, and would really like to avoid making a decision that would consume extra memory and degrade performance purely based on the vague/non-specific/unjustified/fear-motivated 'best-practices' that I've found so far.)

share|improve this question

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.