[Feature Request] Add API support for getting the intial 128bit key used by AES

[jeffreysijuntan]

In CrypTen, we would need multiple parties to share the same source of randomness. In seed based generators, this is done by parties sharing the same seed. In a crypto-secure RNG, this would require obtaining the initial 128 bit key passed to the AES.

It would be helpful to have an API to retrieve the 128-bit key:

urandom_gen = csprng.create_random_device_generator('/dev/urandom')
initial_key = urandom_gen.get_aes_key()
gen2 = csprng.create_random_device_generator()
gen2.set_aes_key(intial_key)

[pbelevich]

What do you think about the following API?

# create a CSPRNG which gets values from /dev/urandom
urandom = csprng.create_random_device_generator('/dev/urandom')
# generate AES128 bit keys in advance(just get 128 bits from /dev/urandom and put into a ubyte cpu tensor)
keys = [csprng.aes128_key_tensor(urandom) for _ in range(0, 10)]

# distribute the keys to the nodes...

for key in keys:
    # on the each node:
    # create a constant generator with the given key
    const_gen = csprng.create_const_generator(key)
    # use it just once as usual(if you repeat usage it will give the same result because the key is constant)
    print(torch.rand(10, device='cuda', generator=const_gen))

@shubho @knottb @jeffreysijuntan @nairbv

[nairbv]

@pbelevich I think it might help if you describe the implementation as it relates to this.

Intuitively it seems that if we're using AES in counter mode, a single AES key (plus the current state of the counter) should be able to generate the same full stream of random numbers on multiple nodes. In that case, maybe we need an API that returns the key plus the current state of the counter?

I think what you're suggesting is that some larger internal state generates a stream of AES keys. If so, it's possible that the user is trying to get the full internal state instead of the key, but I'm not entirely sure.

@jeffreysijuntan IIRC in RNGs in PyTorch we'd use generator's get_state and set_state methods. I think these are currently unimplemented in CSPRNG, but might end up being what we want.

[pbelevich]

@nairbv unfortunately there is no such thing as "the current state of the counter" in current implementation: on each invocation of any random method CSPRNG creates new value for AES128 key and encrypts a sequence of threadIdx values (0, 1, 2, 3...), so the counter starts from 0 each time

[nairbv]

@pbelevich ah, so you mean it gets additional entropy from '/dev/urandom' on each new random tensor generation call, and only uses counter-mode to get a larger set of values to populate the tensor in parallel?

On CUDA, I assume different hardware could have differing numbers of threads, but focusing on CPU, is the RNG deterministic? i.e. if the generator was given an identical entropy source, would it generate identical tensors on different hosts or is it still path/threading dependent?

If it's deterministic, maybe what they would need is an artificial source of "entropy" that provides a mechanism to generate the same set of keys (and thus values) on two different systems? Maybe that provided source of entropy could be another layer of AES in counter mode, though that could require additional security review, at least for caller.

Providing the full set of keys seems like it could be awkward for users.

[jeffreysijuntan]

@pbelevich @nairbv Thanks for working on this. My internship ended at early August so I was able to see your comments until today. I think the API looks fine for CrypTen's use case. I was originally thinking that it would be something similar to the manual_seed method in pytorch where the manual_seed here is the key to the AES. The above API works exactly like that so it looks good to me.

[LaRiffle]

Hi!
Is there any update on this?
From the current README I can set a seed only with create_mt19937_generator and not with create_random_device_generator.
I've seen that there is the PR #53 which I think adresses this, but it doesn't look completed.

Thanks a lot @pbelevich

[pbelevich]

@LaRiffle if you are ok with create_const_generator approach introduced in #53 then I can merge it. If you have any thoughts how the API should look like or any other feedback/suggestions please let me know

[LaRiffle]

@pbelevich I've "approved" the changes on PR, this looks all fine for me! :)

[pbelevich]

@LaRiffle #53 has been merged to master and will be available in nightly builds tomorrow

[LaRiffle]

Thank you very much! Do you know where I will be able to find the builds? On pypi?

[LaRiffle]

Ok got it! pip install --pre torchcsprng -f https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html