Crypto++: How to re-generate pseudo random integers in Crypto++ I'm using Crypto++ to implement my protocol to mask a value $y_i$ by a pseudo-random value $r_i$ such that $m_i=y_i \cdot r_i$. Since there are many $r_i$'s I want to generate them using PRNG and then only store the seed for the PRNG. With the seed any I can regenerate $r_i$, then compute $r^{-1}_i$ to remove $r_i$'s. But in crypto++ the seed (key) cannot be accessible. 

So my question is: how can I use PRNG of crypto++ to accommodate the above technique?

Let $r_i  \stackrel{R} \leftarrow \mathbb{Z}_p$ and $y_i \in \mathbb{Z}_p$, where p is a prime number.
Formally, what you're really looking for is a key derivation function (KDF).

The Crypto++ API includes a PasswordBasedKeyDerivationFunction class, but that doesn't really seem optimal for your purposes; since you already have a high-entropy random seed, what you really want is a simple key-based KDF, not a fancy key-stretching KDF meant for use with passwords.

Fortunately, it's not hard to implement one yourself.  A very simple approach would be to use your "seed" as the key for a stream cipher (or to, say, AES in CTR mode), and use the keystream (which you can obtain by encrypting a bunch of null bytes) as your source of random bytes.

(You can then convert these random bytes into uniform random integers in your desired range e.g. by rejection sampling: to generate a random number between $0$ and $m$ inclusive, first find $k = \lceil\log_2m\rceil$, i.e. the length of $m$ in bits, then generate a random $k$-bit string.  If this bitstring, interpreted as a binary number, is less than or equal to $m$, you're done; else, toss it out and repeat.  It's not hard to prove that, on average, you'll end up rejecting less than half of all bitstrings (since $m \ge \frac12 2^k$).  Note, however, that this does potentially leak some statistical timing information about the most significant bits of $m$, which might matter if you want to keep it secret.)

Alternatively, with only slightly more work, you can implement a standard construction like HKDF (RFC 5869), or one of the DRBG algorithms from NIST SP 800-90A (note: do not implement Dual_EC_DRBG!).  CTR_DRBG, in particular, is very similar to the simple "use seed as key to AES-CTR, take keystream" suggestion above.