Skip to content
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

[Handshake] Support an will_next_write_payload_encrypted #84

Open
fogti opened this issue Mar 30, 2020 · 1 comment
Open

[Handshake] Support an will_next_write_payload_encrypted #84

fogti opened this issue Mar 30, 2020 · 1 comment

Comments

@fogti
Copy link
Contributor

fogti commented Mar 30, 2020

The HandshakeState should have some way to determine if the next payload will be encrypted, where false-negatives are acceptable (and will probably happen if !is_my_turn() and read_message wasn't called yet). e.g. A way to only send a payload with the next write_message if it will be encrypted.

@mcginty
Copy link
Owner

mcginty commented Apr 5, 2020

I agree that this certainly feels more useful than a "was_write_payload_encrypted", which was implemented because it's trivial.

To implement will_write_payload_encrypt feels hairier, because it basically involves doing a "dry run" of the write_message operation without changing internal state, which feels kind of dirty to me. That said, snow does now have checkpointing to recover from errors and avoid having an unknown internal state, and this feature could be used to implement this.

It's definitely going to be a more expensive function to call than its past-tense sibling though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants