Closed creemama closed 3 years ago
this is a scary one, i looked at it - except opaque.c - which is a monster, and then you forcepushed, so i'll look again.
this is a scary one, i looked at it - except opaque.c - which is a monster, and then you forcepushed, so i'll look again.
Would it be less scary if we got this in in parts? If I remove all commits after https://github.com/stef/libopaque/pull/9/commits/8ee608e412c68ca3f6f30bd3328a4e85489fd0c6 , would this pull request be easier to review? At that commit, I finished updating all the variable names in Opaque_UserRecord
.
nah, i'll have another go at it.
hah, looking not at the "changed files" but at each commit individually is much less expensive cognitively. i approve^Wthank you for this. although i must say i don't like the alpha->M and beta->y because for me that makes less sense, but i guess for others who have not come from the paper to the rfc this makes little sense. the other thing i noticed is that the key -> info change is kinda unnecessary since i guess, if the domain separation is correctly implemented, then supplying the key/info parameter is not really necessary and also not in line with the rfc. so i think it makes more sense to get rid of the key/info parameter. also i noticed that the pwhash invocation can be refactored into the prf_finalize function, together perhaps even with the hkdf extract that is tailing the pwash. but those are things for the future. i'll just merge this, and we should later remove the key/info thing and refactor the pwhash thing.
This has the benefit of making it easier to compare our implementation with what's proposed in the draft.