This was an error I introduced when streamlining the previous iteration of the protocol design to always have public verifiability (i.e., it was not included in the Danezis suggestion).
The CEK included in the report must be the one with index j1-1, not index j1, because the recipient of the report cannot verify that the provided CEK was generated bound to rvk. Otherwise a malicious user can submit a report containing a single CEK (the first one) which they did not generate. This mistake was pointed out by Joseph Jaeger and Stefano Tessaro.
To fix this, the report should include cek_{j1-1} rather than cek_j1, and the initial cek_0 should be ratcheted immediately to cek_1, rather than being used to generate a CEN.
Closes #44.
This was an error I introduced when streamlining the previous iteration of the protocol design to always have public verifiability (i.e., it was not included in the Danezis suggestion).
The CEK included in the report must be the one with index
j1-1, not indexj1, because the recipient of the report cannot verify that the provided CEK was generated bound torvk. Otherwise a malicious user can submit a report containing a single CEK (the first one) which they did not generate. This mistake was pointed out by Joseph Jaeger and Stefano Tessaro.To fix this, the report should include
cek_{j1-1}rather thancek_j1, and the initialcek_0should be ratcheted immediately tocek_1, rather than being used to generate a CEN.