Just view simplpedpop PR on github #105
Conversation
burdges
force-pushed
the
jeff-simplpedpop-3
branch
from
593b622
to
480cede
Compare
This is not the correct way to do this, but let's stick with it for the moment.
| @@ -41,7 +41,7 @@ use crate::context::SigningTranscript; | |||
|
|
|||
| use crate::cert::AdaptorCertPublic; | |||
|
|
|||
| fn make_aead<T, AEAD>(mut t: T) -> AEAD | |||
| pub(crate) fn make_aead<T, AEAD>(mut t: T) -> AEAD | |||
There was a problem hiding this comment.
This is not an ideal solution, likely we should be sure we're doing poly1305 right and expose it from here.
| } | ||
|
|
||
| #[cfg(feature = "serde")] | ||
| struct IdentifierVisitor; |
There was a problem hiding this comment.
I'll remove serde from this repo eventually ala #73, so serde should not be used here, and should be avoided for crypto in general.
We do need serialization of course, but this should be done directly as binary, probably little endian.
| .first() | ||
| .expect("This never fails because the minimum threshold of the protocol is 2") | ||
| }) | ||
| .collect(); |
There was a problem hiding this comment.
I see.. You added an extra round so everyone could encrypt to everyone else's f(0) G.
Any idea what blockstream did here? We must treat some input as "PKI", either
- we save ourselves a round by making the user supply encryption keys initially, or else
- make the user provide the round 1 messages from the right people.
I think 1 looks more robust, in the sense that if they provide us a bad public key, then they're clearly buffoons, while 2 requires they do some checking all by themselves.
There was a problem hiding this comment.
Blockstream follows 1.
The idea is that you do not really save a round because you still need to somehow know the encryption keys of the participants, you just save a round in this protocol.
And because of that, it excludes use cases where there is no way of knowing those keys beforehand, or they do not exist.
That being said, I do not have a concrete use case and maybe it is not relevant.
Edit: This does not make sense, since you still need an authenticated channel to send the first messages in a secure way, which requires some keys.
| pub struct PrivateData { | ||
| pub(crate) secret_key: SecretKey, | ||
| pub(crate) secret_polynomial: SecretPolynomial, | ||
| } |
There was a problem hiding this comment.
I mentioned session types way back, meaning this struct should not be clone or serialization, and it shiould be consumed by value later. It's fine if a specific signer device must change this code themselves.
It's also possible it doesn't matter enough here, soi maybe not worth bothering.
There was a problem hiding this comment.
Yeah, I added because I needed them for the tests and benchmarks...Maybe we can add them only as an internal feature?
There was a problem hiding this comment.
In fact, we could immediately trash this data if we fix the encryption and make a two phase sender & reciever thing like I discuss elsewhere.
|
Replaced by #106 |
No description provided.