I'm looking for a way to encode an epoch date / time into an existing string.
Let's say I have a string abcdefghijklmnopqrstuvwxyz and a datetime 1463134905, I need to be able to convert the string into something so that I can retrieve the date from it again and the original datetime.
Using XOR is not an option since I need to know the datetime in order to get the datetime out of it again.
abcdefghijklmnopqrstuvwxyz XOR 1463134905 => result
result XOR 1463134905 => abcdefghijklmnopqrstuvwxyz
So
abcdefghijklmnopqrstuvwxyz (someoperation) 1463134905 => someoutput
Now I want to be able to do
someoutput (someotheroperation1) => 1463134905
someoutput (someotheroperation2) => abcdefghijklmnopqrstuvwxyz
I know I'm adding extra data to the string, so if someoutput needs to become slightly longer, that's also fine, but max 1 or 2 characters, not by the length of the datetime epoch string.
So does a transformation exists that allows me to compact a datetime inside a string and somehow retrieve both the original string and the datetime without increasing the string size by much.
I know Burrows and Wheeler managed to mostly sort a string and unsort it again only storing 1 bit. I'm looking for an algorithm that, just like BWT, can completely change a string and return the original strings.
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.
I think if we have a 32char string with limited alphabet we can code 32bit binary number in it.
alphabet: [0123456789abcdefghijklmnopqrstuvwxyz]
alternate:[ !"#$%&'()ABCDEFGHIJKLMNOPQRSTUVWXYZ]
maximum 32bit unsigned number:
0xffffffff = 4294967295 => Sun, 07 Feb 2106 06:28:15 GMT
input: 5f7a925bb0de0c40e328b93926840459
date: 01010111001101011111111101001000 (1463156552)
output: 5F7A9"%Bb0DE0C4 E#"(B)#)2&84 459
Denny Trebbin
Lead Fullstack Developer. Experimenting with bleeding-edge tech. Irregularly DJ. Hobby drone pilot. Amateur photographer.
I can simply think of tar + de- & compress the data or go all-in with steganography.
How important is it to keep the secret hidden?