We are implementing searchable encryption techniques proposed by Song et al in Java for a paper[1]. The schemes need a Stream Cipher for achieving search over encrypted data. The stream of random bits should be reproducible later while decryption given the same "Seed".

Now we plan to generate the stream of random bits using AES in CTR mode. What we don't understand is what is considered as "seed". Is "seed" the random 64 bits prefix part of the IV / Nonce ?

What would be the plain text CTR mode while generating random stream ? Can we give some hard coded string as plain text as we don't really care what we are encrypting, all we want is random stream of bits that could be reproduced later

Or what is considered a secure way to generate random stream of bits ?

[1] Song, Dawn Xiaoding, David Wagner, and Adrian Perrig. "Practical techniques for searches on encrypted data." Security and Privacy, 2000. S&P 2000. Proceedings. 2000 IEEE Symposium on. IEEE, 2000.

  • $\begingroup$ all the four proposed scheme is one-to-one. i.e. Alice is encrypting data and alice is searching over encrypted data. the server (Bob) search for W in the cipher-text by checking C xor W is of the form <s,F(s)> for some s. with help of key "k" how server compute s,F(s) from <s,F(s)> as the length of s,F(s) are not known. $\endgroup$
    – Aria
    Aug 5, 2015 at 13:35

1 Answer 1


The seed should be the key and the nonce or IV. Those input parameters determine the value of the key stream. Note that the nonce may be implied if the key is not reused, in that case the key may be the only seed, with the nonce having a static value (you should however make sure that you are not vulnerable to multi-target attacks if you use a static IV, see the comment of CodesInChaos below).

For most stream ciphers - such as CTR mode of encryption - the key stream is used to encrypt the plain text by XOR'ing the plain text with the key stream. Obviously if you are just interested in the key stream of N bits then you can simply encrypt a plain text consisting of N bits set to zero (as zero is the identity element for XOR). Depending on the implementation the underlying key stream may also be available directly.

  • 2
    $\begingroup$ Note that even without key-reuse, using a fixed IV enables multi-target attacks. Not a big issue with AES-256, but something I'd avoid with AES-128. $\endgroup$ Sep 4, 2014 at 15:13
  • $\begingroup$ @CodesInChaos Right you are. A good explanation can be found on the Keccak website. The paper in the question discusses general techniques, I guess the choice of mode/key/iv use should be part of a protocol design. $\endgroup$
    – Maarten Bodewes
    Sep 4, 2014 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.