User provided hash function

[rrtoledo]

Why

Support user provided hash functions so that they can address domain separation when using Alba certificates several times in the same application.

What

[rrtoledo]

I think the interfaces of hash functions h0, h1, h2 could be improved. Right now we have to pass parameters like n_p, sec_param, setup, etc, which makes code less readable and more prone to error than interfaces with only essential parameters like in the paper. We could make a struct that takes these "setup" parameters in its constructor and has a hash function that takes only essential parameters.

E.g.,

struct H0 {
setup variables here
}
impl H0 {
func new(setup: &Setup) -> Self {}
func hash(self: &Self, element: Element) -> Option {}
}
Additionally, right now, h1 inputs first_input and second_input are generic arrays and make the callers' job more difficult. Not sure what is the best solution, this comes to mind right now.

struct H1 {
setup variables here
}
impl H1 {
func new(setup: &Setup) -> Self {}
func hash_head(self: &Self, v, t) -> (Hash, Option) {}
func hash_tail(self: &Self, hash, element) -> (Hash, Option) {}
}
Doesn't need to happen in this PR.

[rrtoledo]

We pass sec_param here but store n_p in Round, both are used only for h1. Either we should 1) pass both here, 2) store both in Round, or ideally 3) store a hash function in Round instead of auxiliary parameters for it.

We can leave it for future work, but the way it is right now feels clunky. We can address it when optimizing DFS not to copy elements list for every step. The way I usually do this is by creating a struct just for the DFS that has a mutable elements list as a member and a recursive dfs function. Feels like, we can improve code structure during that task.

[rrtoledo]

I think a long string like "Telescope-H1" is not necessary. Suggest this at the top of the file.

mod hash_domain {
const H0: u8 = 0;
const H1: u8 = 1;
const H2: u8 = 2;
}