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.
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.