Would it be feasible to give two parties a seed to generate random numbers? So that when they want to send data to each other they send the correction on the random number generated?

The random number generated: 110001
Data you want to send: 101010
Correction you send(with 1 good and 0 false): 100100

Obviously, this could only work in a small group (with trusted members) and the seed would need to be stored safely. Other than this could this system actually have a use?

  • 2
    $\begingroup$ You are describing a stream cipher used with a shared symmetric key (the seed), applied on the plaintext with the operator NOT XOR instead of the more common XOR. $\endgroup$ – A. Hersean May 3 '19 at 12:54
  • 2
    $\begingroup$ NOT XOR is commonly called XNOR as far as I've seen. With regards to random number generation, practically speaking you should not use a PRNG for this, as PRNG implementations may e.g. reseed, change implementation specifics etc. A stream cipher is the way to go, but of course you'd need a ~128 bit or larger seed for it to be secure. $\endgroup$ – Maarten Bodewes May 3 '19 at 14:21
  • $\begingroup$ You can also use 2's complement ~(a+b)+1 as the operator. The principle key management difficulty with any crypto remains how to share the seeds or keys to begin with. As regards PRNG implementations, how is this different than, for instance AES implementations? $\endgroup$ – outer May 3 '19 at 22:34
  • $\begingroup$ @outer - AES has standardized modes of operation, implementations using a given mode won't rekey on their own. CSPRNGs will reseed periodically. You'd have to specify a standard that prevents this, and since a lot of the most common CSPRNGs are just stream ciphers with the entropy pool as a key you're back to using a stream cipher anyway so you can skip the complication. EG CTR-DRBG uses AES-CTR (stream cipher mode of AES) as a PRNG keyed from an entropy pool. $\endgroup$ – SAI Peregrinus May 4 '19 at 1:56
  • $\begingroup$ What I meant was how is verifying the implementation of a PRNG any different than verifying an AES implementation, or any CSPRNG based on AES, like the one you mentioned? Even AES will run out eventually, and (for a given key & nonce) it's not safe to use as a keystream past 2**64, richtig? $\endgroup$ – outer May 6 '19 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.