Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bug in second hash calculation #141
Fix bug in second hash calculation #141
Changes from 5 commits
fc6b7af
211c6ea
d52a261
97b536b
f71ac58
8397bed
3c83f4e
b6de4a3
bf7b779
f46ab32
db78586
b96a4f7
3318d7d
5fbbb28
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concerning the payloadLen, the exact format isn't defined yet in ipfs/specs#373.
Would it make more sense to use a constant byte array (e.g
make([]byte, 8)
) or to use an unsigned varint. As we mostly encrypt peerids, that are quite short, we don't always need a big number for the payload len. A varint allows to use less bytes to describe the payload len, and the maximal payload len can also be very large if needed.I think that I am more in favor of an unsigned varint format for the payload len, as it gives more agility. WDYT?
cc: @ischasny @Jorropo @masih
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These values are hashed over, so
payloadLen
isn't going to be a part of the encrypted value, i.e. see line 79:nonce := sha256Multiple(nil, noncePrefix, payloadLen, payload, passphrase)[:nonceLen]
.Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, all good! 👍🏻
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The format for Encrypted PeerID/Metadata was recently updated in the DHT Spec. The format should be [
encryption_varint
,payload_len
,nonce
,encrypted_payload
]. See ipfs/specs#373The encryption varint for
aes-gcm-256
is0x8040
and the multicodec is0x2000
(See multiformats/multicodec#314 (comment))There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point! As IPNI doesn't have anything stored after
EncPeerID
theencryption_varint
andpayload_len
can be appended on retrieval.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, just wanted to make sure we are on the same page 😄