Generating two secret keys from a physical analog signal: Crypto HASH analogous to time varying signal Can we generate two secret keys from same source?

The idea is we have time varying signal. We capture a window of say few milliseconds,$t$. I can chop values of signals at a rate $N_S$ and get $tN_S/1000$ samples. I put a threshold and assign 0 and 1 to values below and above it.
Since this signal is shared I get a secret key of length $tN_S/1000$ bits.

Now the length of key depends on $N_S$ for a given window. We do agree that it gets harder to track original data if I decrease this $N_S$.

My problem is can I generate two different secret keys using this time varying signal. Approach can be to to use different functions say: digitization and derivatives. I can encode derivative to some bits.

These two functions can give two separate sequences. Now issue is I cannot say I have got additional level of security because: Signal can be compromised and that will compromise both functions results. This is what happens in general cyrpoto key management. 
Another point is I can use first method(thresholding) to generate back signal and guess output of second sequence hence its useless to generate that sequence!

My point is viability of back generation of signal depends on sampling rate.If its high the second sequence can be broken. But if sampling is low enough then back generation will be erratic hence second sequence cannot be guessed correctly.

I feel sampling can be optimized and keys generated through one process is not able to capture the full prowess of source and I can generate more keys from the signal which is still secure be it of a small length.

Is there any method already studied in literature of generating two secrets from a signal?

Hash is one practice that is effective in key management but the security level is decided by parent key no matter how many hashed keys we generate ahead. But if we generate two keys from a physical signal(assuming this signal is shared and random enough and cannot be guessed by eavesdropper) can the security level of system be increased?

If not are there analogous to hash functions on such time series signals?
If not one way functions how can we compare feasibility of choosing two such functions? Is cross correlation a good choice?
There seem to be multiple problems you try and solve at once. Lets split the problem in at least two sub-problems:


First of all you want to have to extract entropy;
Then you want to create two keys using the entropy or random number generator.


Extracting the entropy

Extracting the entropy from the source involves whitening techniques. In case the amount of entropy is low you may want to use this entropy as input to a DRBG (deterministic random bit generator).

You may also want to include other entropy sources or identifiers, anything that may add randomness if you're using a DRBG.

Lets call the resulting bit string with $K_{master}$. $K_{master}$ does not have to be formatted as a key, it's just a bunch of bits that together hold a minimum amount of entropy.

Creating two separate keys

OK, so now you need two separate keys that are independent on each other. This is easier then you may think; you can simply use a KBKDF such as HKDF, which is based on a hash function: $K_1 = \operatorname{KBKDF}(K_{master}, \text{"1"}, l)$ and $K_2 = \operatorname{KBKDF}(K_{master}, \text{"2"}, l)$ (where $l$ is the amount of bits required for $K_1$ and $K_2$.

HKDF first explicitly extracts ("compresses") the entropy in the key to a fixed size output that depends on the hash algorithm used. It then expands this extracted information into enough key material for $K_1$ and $K_2$. Of course the strength is limited by the entropy in the input key material and the used hash function (however SHA-256 or higher should be enough for any normal usage).

You could include a device specific secret into the IKM by appending or prefixing it to the $K_{master}$ that you got from whitening your entropy source.

Most importantly, revealing either $K_1$ or $K_2$ to an attacker won't give the attacker any information on the other key or the input keying material (given it has enough entropy not to be brute forced).



This way you can focus on the best way to get entropy from your source. Try not to create any data that depend on other data as you seem to suggest.