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

Add Offset to Crypt and migrate all reply/segmented two cipher constructions to the Offset #15

Open
l0k18 opened this issue Aug 6, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@l0k18
Copy link
Collaborator

l0k18 commented Aug 6, 2023

In order to further diminish differentiation between messages by evil nodes, the Forward and Reverse messages are eliminated in favour of Forward, and to serve the function of enabling a header/payload sectioning of messages where the header is shuffled upwards with each layer and the payload encrypted using the second, "Payload" key, the Crypt is being extended.

As mentioned in #13 the objective is to make it possible to vary the constructions of reply messages and more deeply conceal the differences visible to relays between client initiated and response messages.

As such, for forwarding layers, we want to be able to make any length, and for the offsets on each crypt to refer to the same point where the Payload key is used with the provided header, nonce and cipher sets.

As such, this process can proceed such that pieces are added before the thing they replace is removed. The offsets will first be added to the Crypt message, then the proper values computed, then the check on the other side to ensure they are coming out correctly, and then the builder functions for the common message constructions needs to be revised to enable the 2+, variable length construction. On the read side, just to first ensure the fixed sized 3 part reply routing headers match the offset in the crypt to the old way of computing it.

With all of that working, the "Reverse" message can then be removed, and the forward side construction in the Exit message, and the relevant hidden service related messages can then be switched over to use the multi-layer construction with two or more sessions designated.

Everything subsequent and built upon the Exit message is affected by this change, as they all require 2 and longer segmented encryption. The Exit message originally didn't have a segmented header but then it was realised that it could be and this made the request and response indistinguishable as regards to their intermediary hops.

@l0k18 l0k18 added the enhancement New feature or request label Aug 6, 2023
@l0k18 l0k18 self-assigned this Aug 6, 2023
@l0k18 l0k18 moved this to In Progress in indra kanban Aug 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant