Popular posts

I'm trying to embed a date inside an encryption key so that I can warn a user if his encryption key is older than a certain number days / months / years. Due to legacy systems (that I don't have control over) using this encryption system, they can't store a date that the key was created and for security reasons, I can't store keys next to dates in the encryption system, so the most feasible way to store it is inside the keys themselves. Visibility is not much of an issue, as long as it's not easy to change it.

The concept of Steganography is exactly what I'm looking for, but all the algorithms for it usually hides stuff in noise / data that can be tampered with, I only have exact data, no noise.

I've started writing my own compression algorithm to reduce the bits in the key, I'll just need to mathematically prove that I will always have those number of bits available after compression, if not, I risk increasing the length of the key.

Ok, I think we can't in the digital world merge different data into the same media without adding noise. And I believe, but I'm not sure about the age of your security system that it won't accept keys with extraordinary length. If the decoder works with 256 bits and you use a key with 278 bits, it may reject the key if the decoder is safe. I would use a key store to store the date of the key and the hash of the key to identifying a key again but not risking to lose the key to some strangers.

The client's system can only handle keys up to 32 characters long, but it appears to be all stored in lowercase HEX (I'll need to confirm that though) - by introducing uppercase HEX characters, it seems I'll have just enough extra bits to store the date in the key and still pass their validation. Legacy stuff, ugh