I've recently come across a situation where one system passes an encrypted payload to another system. The payload is encrypted using a pre-shared key. However, instead of just using the key itself, a calculation is made using the current day and month to produce an integer value. This value is then used to retrieve a substring of the key. So if the output of the calculation is 10, the key used to encrypt the payload is a substring of the original key beginning at the index of 10. Both systems have this logic.

I understand this prevents someone who possesses the key but not the aforementioned logic from decrypting payloads, but is this necessary or an industry standard solution to this problem? I've never encountered it before and I'm not sure what terms to use for further research.

Any insight is appreciated!

EDIT: I suppose the original "key" isn't really a key...it's a password the keys are derived from.


It is definitely not an industry standard solution. It looks like what the system designer wants to enforce is changing the key everyday. Essentially, it is a naive (and not secure) session key scheme such that each session lasts a day.

The idea of using session key is quite common in secure communication. Cryptanalysis becomes easier if the attacker can have more ciphertexts encrypted with a specific key. Thus often we want to limit the amount of data encrypted under a particular key. This is done by key exchange/establishment protocols that generate random, short-lived keys and secure distribute to sender/receiver. The random keys are called session keys because they are only used in one session. The security of the distribution usually requires e.g. a pre-shared key or asymmetric keys.

Going back to the scheme you mentioned, it is not secure because of many design flaws, e.g. the session keys are not randomly generated, are related to the pre-shared key, and can be re-used. It does not provide much additional security, e.g. if the attacker possess the pre-shared key, he can enumerate the session keys without much effort. It may even weaken the security of the system.

  • $\begingroup$ Thank you! This is what I suspected. Do you have any recommendations for alternative designs? I have an opportunity to improve this system and I'd like to research alternatives before simply saying "the current design is insecure." $\endgroup$ – Troy Carlson Sep 7 '18 at 16:36
  • 1
    $\begingroup$ I guess it would depend on your requirements and system architecture. However, depending your experience or knowledge, it may be easier or safer to adopt an industry standard protocol such as TLS than designing your own protocol. $\endgroup$ – Changyu Dong Sep 8 '18 at 9:48

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.