On Wed, Dec 17, 2014 at 1:11 PM, Ryan Kelly <[email protected]> wrote:
> On 18/12/2014 04:24, jr conlin wrote: > >> On face, it looks reasonable. I'd introduce a bit of extra nonce to the >> key generation sequence (otherwise it's conceivable that the master >> could be derived from enough samples as well as it being possible to >> predict keys). >> > > HKDF *should* be sufficient protection here. > > Importantly, we need the derived keys to be stable - if the same relier > does the OAuth dance with the same user, it should get the same kAr and > kBr. So this limits the amount of salting/noncing we can do. > Noncing (in the sense of a random thing generated fresh each interaction) is out, since all clients need to agree on all parameters every time they approach an interaction. But we can salt (in the sense of a random thing generated once for each user) a little, since the content server and oauth backend have an open channel. It's not clear why that would be interesting, since the key being fed into HKDF is already supposed to be strong, and the choice of parameter is arbitrary (and all are assumed to be strong). But we could do it. Nick
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
