Home/ Questions/Q 6686525
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T05:10:54+00:00

I am creating a protocol which tries to ‘store’ symmetric key sessions for later.

  • 0

I am creating a protocol which tries to ‘store’ symmetric key sessions for later. I store three things: the session_id (public), symmetric_key (private), and counter/nonce (private). With every transmission, the session_id is transmitted in the clear and used to lookup the symmetric_key. The symmetric key is used to decrypt the data. The data contains a hash(sha256) which is used to verify message contents. Then, I extract the nonce from the contents and check that it matches the stored nonce. If it does i increment the stored nonce by 1. Otherwise, the packet is fake and I toss it. Currently, I use the nonce as the IV for the symmetric_key. Is this an error? Must I use a completely random IV? Lastly, If I do use a random IV, then how do I transmit more than once? Do I need to renegotiate a new key? I am using the mcrypt library to do this.

To be clear, the client is sending: [nonce + data + hash(data+nonce)]encrypted + session_key

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I will restrict my answer to the use of random IV.
    I assume that you are using Cipher Block Chaining (CBC) mode that requires an IV.

    Note that that the IV is not encrypted (as the receiving party needs that for decrypting the first block of data) and so if you are using nonce as the IV, instead of saying [nonce + data + hash(data+nonce)]encrypted it is more precise to say nonce + [data + hash(data+nonce)]encrypted, where + denotes concatenation.

    RFC 2451 “The ESP CBC-Mode Cipher Algorithms” says “The IV MUST be chosen at random. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm’s blocksize.”

    In addition to being random, the IV should also be unpredictable. The earlier practice of using the last ciphertext block of the previous message as IV — which though random is predictable — is flawed. This flaw, however, is of concern to you only if the adversary can mount a chosen plain text attack. That is, if the attacker can send chosen plain text to be encrypted and be able to see the result. Obviously, a nonce, while unique, is predictable.

    It is better to use a random IV. You can seed a PRNG and generate IVs and conservatively re-seed well before the sequence repeats. When re-seeding, it is also good idea to use key-exchange and change the symmetric key. This will ensure that for a given key you never use the same IV twice.

    For more info on chosen plain text attack, see Why is using a Non-Random IV with CBC Mode a vulnerability?

    • 0