-1
$\begingroup$

Supposed that a client has AES-128 bit randomly generated static key

The client is using a PBKDF2 in order to to generate a vector(list) of keys i.e. target keys to leverage will be located between the range of index’s i.e. 20 000 till 80 000. basically that means that the client has around different 60 000 keys that could be possibly used.

I would like to understand if there is any specific reason why NOT to do the following in two different scenarios:

A) The client is using AES CTR mode with randomly generated 16 Bytes IV on the client side using the browser RNG. Basically only the first 8 byte the nounce i.e. the first 64 bits most significant bits are random the rest is the counter. Unfortunately this is a restriction on the client side that can not be changed. The concern here is that different browsers are providing different types of RNG and in case for some reason the IV's repeat, this will not end good. Since the client is not expected to have more then 60 000 data chunks that will need to processed, will it be a an acceptable idea to circle trough the the space of keys between 20 000 and 80 000 and used one of the following keys i.e. from the range PBKDF run 20 000 till PBKDF run 80 000 during the encryption process. That would also mean that the key index that will be used will also need to be saved and send together with the Counter(IV), ciphertext and MAC as a public information.

B) Is the security completely broken in case for some reason the number of data chunks overflow the 60 000 counter and in this case at least two IVs(counters) repeat but their keys are hopefully different.

Many thanks in advanced.

$\endgroup$
  • $\begingroup$ "The client is using a PBKDF2 in order to to generate a vector(list) of keys i.e. target keys to leverage will be located between the range of index’s i.e. 20 000 till 80 000. basically that means that the client has around different 60 000 keys that could be possibly used. " Could you revisit these sentences, possibly make them shorter or more formalized? It's not completely clear what you mean with "located" here. Also, it is not clear if keys are reused between browsers and such - this is why we prefer text to be accompanied with a formal protocol description. $\endgroup$ – Maarten Bodewes Jan 9 at 13:35
  • $\begingroup$ @MaartenBodewes thank you for the quick reply. I would like to explain what i mean with this seance. I would like to run the the PBKDF at least 80 000 times and save all key generated from the index 20 000 to 80 000 in a vector/list this list. With the word located i wanted to specify the space of keys between PBKDF2 run 20 000 and PBKDF2 run 80 000. $\endgroup$ – Tito Jan 9 at 14:50
  • 1
    $\begingroup$ I think this is where PBKDF2 with a single salt, followed up by a KBKDF such as HKDF would be a better design. As for the counter mode: as long as there is no repetition of a key / counter pair then you're using CTR mode correctly. There isn't much more to it. Usually this is performed by having a unique nonce in the first - most significant - 64 bits or so and the counter in the 64 least significant bits. I'm not sure what other information you require from the given question. When asked to clarify, please clarify by editing the question - comments may not be permanent. $\endgroup$ – Maarten Bodewes Jan 9 at 14:55
  • $\begingroup$ Basically in order to simplify my question here i would like to rephrase it: lets say we have one key and we have runner the PBKDF 3 times and now for some reason it happens that we encrypt some data let say data1 and data2 with the the PBKDF key 2 and PBKDF key 3, but the in both cases the IV(counters) are the same. Will that break the security if alice sends to bob the ciphertext together with the unsigned key index number used by the PBKDF and the MAC. I.e. Basically i am trying to find out if this could help in cases if IV's repeat. $\endgroup$ – Tito Jan 9 at 15:02
  • $\begingroup$ I don't see how you'd select the key if you don't trust your randomness source. I could recommend GCM-SIV for this where you extract the entropy available to you into a 96 bit nonce, but I'm afraid that's a bit out of your league. $\endgroup$ – Maarten Bodewes Jan 9 at 15:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.