Extracting randomness from highly-biased RNG I have a source with a very low entropy (like 3 entropy bits per 1024 source bits). But I need to construct a 128 bit seed from the source. 

Will it be helpful to XOR 350 bits with jump 128 bits, e.g. $n_0\oplus n_{128}\oplus\dots\oplus n_{128*350}$ or maybe some more times?

EDIT:
The source is SRAM so the bits are fairly independent.
Distribution of min-entropy is on the histogram. The first bar is like 500 bits, but the others are much lower so I cut the first one.
If the source as 3 entropy bits per 1024 source bits, constructing a 128-bit seed requires $\lceil128\cdot 1024/3\rceil=43691$ source bits at least.

The "XOR 350 bits with jump 128 bits" translates to (correcting the question's formula)
$$o_i=n_i\oplus n_{i+128}\oplus n_{i+2\cdot128}\oplus n_{i+3\cdot128}\oplus\dots\oplus n_{i+348\cdot128}\oplus n_{i+349\cdot128}$$
That can not be guaranteed to work. For example, a source that outputs one truly random independent unbiased bit every precisely 256 bits, and outputs 0 the rest of the time, has a rate of 4 entropy bits per 1024 bits, but the 128-bit seed generated by the proposed method has a single bit of entropy (and worse, can take only two values).

Without a model of the source, a common solution is to hash the entropy source. That protects against a wide array of accidental failure modes (like unwanted feedback of the conditioned output to the entropy source). Of course, it remains of paramount importance, and difficult, to reliably detect a broken or rigged source that does not meet its assumed entropy rate.

For the utmost output entropy and common Merkle-Damgård hashes, it is best to truncate a hash wider than the output: there may not be quite 256-bit entropy in the output of SHA-256 with ample entropy in the input, in particular if the last message block hashed is constant. So for a 256-bit seed it is best to use SHA-512/256. For up to desired 240-bit seed, and all except adversarially rigged entropy source, SHA-256 truncated to the seed width is fine.

It is reasonable to use HMAC-SHA-512(K, N) truncated to the seed size, where N is the input entropy, and K remains unknown to the designer of the entropy source; this way, the best said designer can hope is make the output repeat, but s/he has no control on the values at the output.



EDIT: if the source is (the power-on state of) SRAM, and its addressing is natural (matches physical organization), then the proposed "XOR bits with jump 128 bits" entropy extractor makes me especially nervous: it is all too possible that all the bits entering a given $o_i$ share a common bias, because they are on the same row or column (or a small number of these). Using an odd jump could help somewhat. This illustrates the need to have a model of an entropy source to make recommendations about its conditioning.

Also, beware that adversarial control of the power-on conditions might reduce your entropy rate (think system reset without a power cycle after the RAM has been set to a repeatable state, slow controlled power rise at low temperature obtained by evaporation of an appropriate liquefied gaz, and other things hackers do); and that some marketed-as-SRAM really is DRAM with a hidden refresh, or could become so for cost-optimization reasons.

Even with the same mask set, the entropy rate might change drastically from one fabrication batch to another; it should at least be validated on "corner lot" wafers. Even if things are done once at wafer testing time, don't assume that all wafer testers will yield the same entropy, and that it won't depend on the testing temperature, which someone at the fab might decide to change (e.g it is common that at start of production of a new chip test is performed at several controlled temperatures, then move to different temperature(s) when the process has stabilized).



EDIT2: If the thing must be done in silicon, a 128-bit CRC for the source might be the way to go, e.g. using primitive polynomial $x^{128}+x^{99}+x^{62}+x^{33}+1$ (source: eq-primpoly-w5.txt in Jörg Arndt's useful and ugly page of mathematical data).

In a non-adversarial context, a CRC is a fine alternative to a hash, because for any natural entropy source (not designed with knowledge of the CRC polynomial, and not influenced by the CRC being computed), the output will be unbiased, and all input bits will have the opportunity to influence all output bits (for standard definition of CRC in crypto and telecoms, that is remainder of the division by the CRC polynomial of degree $k$ of a polynomial of degree $m+k$ which $m$ high-order coefficients are the entropy bits, and the $k$ low-order bits are zero).

Notice that "I don't have place to store all the needed ~50 Kbits" is no excuse not to use a hash or MAC: SHA-256 and HMAC-SHA-256 can be computed with 128 bytes of temporary memory, regardless of the input length.



FINAL NOTE: With that idea of RAM content as entropy source, be at the very least cautious about the (aforementioned) attack where an adversary makes a reset (or many) without removing power!