facebook
Adding support for HistoryProofV2
The main change in this PR is the introduction of HistoryProofV2 which improves security properties for limited history proofs. It is based upon https://github.com/facebook/akd/pull/422, with changes to maintain backward compatibility and support unit tests for both versions of history proof.
- Added HistoryProofV2 struct and key_history_v2 and key_history_verify_v2 functions which generates and verifies HistoryProofV2.
- Extended HistoryVerificationParams to include information about the HistoryParams, to be used during the proof verification.
- Removes HistoryParams::SinceEpoch. The only way for specifying a non-default parameter now is with HistoryParams::MostRecent.
- Added a new get_marker_versions() utility function which determines the past and future version numbers to check as part of the HistoryProofV2 generation and verification
- Moved HistoryParams out from akd and into akd_core since it is also used by verification
- Added a new InvalidVersion error type
- Added tests for HistoryProofV2
- updated docs
- Bumping the version to 0.12.0-pre.1
@dillonrg -- I saw that Kevin has renamed in PR428 the MostRecent to MostRecentInsecure in HistoryParams. Since I am reusing MostRecent for history V2 as well that created a merge conflict. I have thought there are two options
1/ Rename it back to MostRecent. This is the easiest and since in this PR explicitly mark V1 of HistoryProof as deprecate, it feels like risk of misuse is small.
2/ Leave HistoryParams untouched and add a new struct HistoryParamsV2 (similarly, HistoryVerificationParamsV2). This makes the message clearer but the unit tests macros that I have added in this PR will need to be modified to pass in those structs as parameters.
Let me know what you think and I can make the changes!
cc @kevinlewi for FYI.
@haochenuw Thanks for working on this!
I think, rather than having a key_history() and key_history_v2() interface, it might be better to instead just have one key_history() function, but add an additional parameter that allows the caller to essentially specify the version. Then, the return of the function can be an enum, something like:
pub enum KeyHistoryResult {
V1(V1Struct),
V2(V2Struct),
}
which can be parsed by key_history_verify() as well. That way, we also avoid having to throw everything into macros for the tests that test both versions.
Let me know what you think about the suggested change... I am hoping it will lead to a smaller change overall and simpler code.
Also, no need to push each commit to the PR, you can just force-push to erase the history and have a single commit change for the PR.
