Core vs message generators

[andrewwhitehead]

At the moment we have separate generator seed values within each ciphersuite used to generate the 'H_s' and 'H_d' generators. This could be made a little more efficient by using a single seed value and defining these generators as the successive outputs.

Instead of blind_value_generator_seed and signature_dst_generator_seed I would suggest a something like a core_generator_seed. Then H_s becomes the first output of CreateGenerators(dst, core_generator_seed, 2) and H_d the second.

Syntax wise, we could use an alternative naming for these generators and refer to them by their number, consistent with the H_i generators. Perhaps Q_i?

Additionally, we could potentially solve the holder binding issue (#37) by replacing P1 with Q_1, making H_s and H_d the subsequent generators (Q_2 and Q_3) and freeing up P1 for application usage.

[andrewwhitehead]

To my knowledge P1 serves two purposes in the original formulation. For a signature over messages m_i, with B = P1 + H_0*s + H_1*m_1 ...

1. The signature can't be multiplied by a scalar in order to present alternative message values. For example, setting A1 = A*n, s1 = s*n, the signature (A1, e, s1) might be valid over messages m_i*n except for the fact that P1 becomes P1*n. In a sense we can think of P1 as a message generator which always signs the message scalar 1.

2. As part of the zero knowledge proof for disclosed messages D, the equation P1 + sum(i in D, H_i*m_i) = sum(i not in D, H_i*m_i) is proven. In the case where no messages are disclosed, only P1 is left on the left hand side.

In the current formulation we always have at least one revealed message (the domain), and so there is always something on the left hand side of the proof equation. Since the domain value is generated by a hash, it would also be extremely difficult to choose a header message such that a chosen scalar multiple of the domain value could be substituted. I believe this means we could technically do away with P1 entirely (but that would mean updating the proofs and so it's probably not worthwhile).

[BasileiosKal]

I don’t think it is possible to NOT use P1 (or not "sign" 1 in general, under any generator). If the signature is A = (Q1 * domain_1 + sum(i in L, H_i * m_i)) * (1/(e +SK)) then i can calculate any domain_2 i want, set k = domain_2 / domain_1 and calculate

A * k = (Q1 * domain_1 * k  + sum(i in L, H_i * (m_i * k))) * (1 / (e + SK)) 
        = (Q1 * domain_2  + sum(i in L, H_i * (m_i * k))) * (1 / (e + SK)) 

Which is a signature on domain_2 and the messages m_i * k?? Unless im missing something.

That said I’m not opposed with using 1 seed for all "core" generators and on freeing P1, by substituting it with another generator. I don't think from an implementation’s perspective it makes much difference and we are at the very least enabling some interesting use cases

[andrewwhitehead]

That's a good point, you could make it work for some k, but not a chosen value. Scratch the part about removing P1 then.

[andrewwhitehead]

Closing. Might still consider renaming the H_s and H_d generators.