-
Notifications
You must be signed in to change notification settings - Fork 21.6k
Whisper v6 remove aesnonce #15578
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
Whisper v6 remove aesnonce #15578
Conversation
|
@gluk256 Unit tests aren't finished yet, they are part of an upcoming commit so don't press the 'accept' button before they are there. |
whisper/whisperv6/doc.go
Outdated
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.
Why did you make this change?
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.
Because the EIP-627 packet codes specifies that:
The message codes reserved for Whisper protocol: 0 - 127. Messages with unknown codes must be ignored, for forward compatibility of future versions.
Support for messages with codes 126 and 127 will be added in subsequent PRs.
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.
This change to EIP was made after discussion with Robert (Parity) several months ago.
|
@gballet please run |
|
Travis says: |
|
This is weird because the diff doesn't actually apply to envelope.go |
The aes nonce is now part of the payload of a symmetric message. Since there is no futher available indication whether a message is symmetric or not, functions isSymmetric and isAsymmetric have been removed and a symmetric topic match will be attempted if the filter is symmetric. Accordingly, other checks have been removed at the top level, because they can no longer be performed until it is known for a fact that the message uses symmetric encryption.
That was left out in the last commit.
There is an ongoing discussion whether this is the proper way to go, as filters implementing both sym and asym keys will see an unsuccessful attempt at an asymmetric decryption be followed by an attempt at a symmetric decription. This is inefficient in that case, which should not happen too often. The alternative is to forbid using filters with both options enabled, and will require updating unit tests.
It has been decided not to allow filters to be both for symmetric and asymmetric keys, because that's already what the API enforces.
a74db4c to
35297a8
Compare
|
Rebased. This should be OK now. |
As per EIP-627, the salt for symmetric encryption is now part of the payload. This commit does that.
As per EIP-627, the Salt for symmetric encryption is now part of the payload. This commit does that.