provider record encryption #3
Conversation
…ad-dht into noot/provider-encrypt
pb/dht.pb.go
Outdated
| // signature of the provided key + encrypted peer ID for ADD_PROVIDER messages | ||
| Signature []byte `protobuf:"bytes,5,opt,name=signature,proto3" json:"signature,omitempty"` | ||
| // public key of the peer for ADD_PROVIDER messages | ||
| PublicKey *pb1.PublicKey `protobuf:"bytes,6,opt,name=publicKey,proto3" json:"publicKey,omitempty"` |
There was a problem hiding this comment.
Is the public key required in the message's content?
If we only want peers to publish content that they provide themselves, then this is not required. The public key can be derived from the peerID. However, it is useful in the case we want to allow peers to publish content that they do not provide.
There was a problem hiding this comment.
ah, is it possible to derive the public key from the peer ID? I thought the peer ID was a hash of the public key, (https://github.com/libp2p/go-libp2p/blob/1ad0a50be62b1e00388b9d85fc997d66e8910c9d/core/peer/peer.go#L179) so I had to send the public key in the message to verify the signature.
…ad-dht into noot/provider-encrypt
| "github.com/multiformats/go-multihash" | ||
| ) | ||
|
|
||
| const ( |
There was a problem hiding this comment.
Would it be possible to get these constants from somewhere where they are already defined instead of defining them again? This would help with code maintainability :)
There was a problem hiding this comment.
unfortunately the Go AES package doesn't define these :/ I'll try looking somewhere for them!
There was a problem hiding this comment.
We should be able to get Nonce size from cipher.AEAD interface.
…ad-dht into noot/provider-encrypt
…ad-dht into noot/provider-encrypt
…ad-dht into noot/provider-encrypt
…ad-dht into noot/provider-encrypt
| } | ||
|
|
||
| ct := aesgcm.Seal(nil, nonce, plaintext, nil) | ||
| return append(nonce, ct...), nil |
There was a problem hiding this comment.
We probably need to append encryption algorithm here too so that the encryption function rotation doesn't require coordinated client update. I.e. for example AESGCM || nonce || enc(payload). That would also allow to have different encryption functions in the same DHT.
There was a problem hiding this comment.
This is going to add 6 bytes to every encrypted value. Can we use a varint as code for AESGSM, then update the spec to document it?
There was a problem hiding this comment.
@masih do you have a pointer to the AESGCM varint?
There was a problem hiding this comment.
I believe we will have to define this mask ourselves and then document in the spec what that number means
There was a problem hiding this comment.
Right. We'd need to define those in the spec ourselves.
This can also be a new multicodec. I recommend picking a varint that's not reserved already to have the option of adding it to the multicodec table later on.
ADD_PROVIDERmessage, include signature of messagekey || encrypted peer IDADD_PROVIDERmessage, verify this signatureProviderManagerto only deal with peer IDs, simplifies the code somewhat as it was only accepting peer IDs anyways