Make non-threshold crypto in SyncKeyGen pluggable.

[afck]

It uses default arguments so that existing code does not need to be changed.

[afck]

I'm unsure; please let me know your opinion:

• Is it overengineering to make Part<C> and Ack<C> generic in the ciphertext type C? Almost all crypto implementations will probably just use C = Vec<u8> there, so we might as well hard-code it, and include serialization in the PublicKey/SecretKey implementations?
• I'll probably update DynamicHoneyBadger accordingly, too. Or is it better to keep it simple, because it's going to be used as a reference implementation rather than directly?
• @dforsten: Does the interface fit what we'll need in Parity? Will we able to borrow, copy or smartly reference the private key or engine signer in a way that we can pass ownership to a SecretKey implementation into SyncKeyGen? Or should we change the API so that it's passed into every handle_part/handle_ack call instead? And our traits also don't need to know about auth_data, do they?

[vkomenda]

• Is it overengineering to make Part<C> and Ack<C> generic in the ciphertext type C? Almost all crypto implementations will probably just use C = Vec<u8> there, so we might as well hard-code it, and include serialization in the PublicKey/SecretKey implementations?

I think C can be hardcoded as Vec<u8> the same way as ProposedValue in subset. We have other examples of hardcoded Vec<u8>. That might rule out some character encodings though but there is an argument that in fact sounds more in favour of using Vec<u8> in cryptography than text strings.

• I'll probably update DynamicHoneyBadger accordingly, too. Or is it better to keep it simple, because it's going to be used as a reference implementation rather than directly?

Maybe for the reference sake you could show how DHB would use pluggable SyncKeyGen. But that could be a PR of its own.

[afck]

Done. The disadvantage with this approach is that serialization and deserialization of the BLS ciphertext are now part of the PublicKey/SecretKey trait implementation. That means those traits have an associated Error type, and with BLS we do some redundant serialization, i.e. serialize Ciphertext into a Vec<u8> that is part of a message that gets serialized later. But I guess it's still simpler this way.

[dforsten]

The EngineSigner passed to Parity Consensus Engines only exposes "sign" and "address" functions, which will not be sufficient for general-purpose encryption/decryption. We will have to acquire the signer's keypair through other means, e.g. from an account provider, which allows access to the secret.

As soon as we have access to the secret in Parity I see no problem implementing SyncKeyGen's SecretKey and PublicKey traits.