On 10/17/17 5:50 PM, James McGlasan wrote: > Why aren't you authenticating? We want to reduce malleability and > tagging attacks! Sphinx and HORNET use unauthenticated encryption for > the payload and a MAC to authenticate the payload and header, you may > instead use an MRAE[AAD] where the header is the AAD and the tag may be > detached and sent in place of the MAC. My understanding of the subject is probably not deep enough, but as I understand it right now, you can't hide the number of hops and use authenticated encryption on each hop and also have a fixed length of the final message. I mean, you can reserve space for up to X hops, while Y <= X hops are actually used, but this inherently means larger overhead, which for small total message size might be very costly.
> You almost described a tagging attack. You want to discard early or let > the client detect the event and decide if they want to distrust any > intermediate relays. It seems like dropping packets early is also a useful information for global observer. I'm wondering if there are any ciphers out there for which the use of multiple layers of encryption might resist malleability on the receiving side (note: in case of Ronion, there is a possibility to have a shared state between initiator and each hop/relay in the circuit). This would simplify everything a lot. Also in my use case I think traffic shaping can be made very hard if all of the nodes in DHT are constantly sending data on each link at fixed rate. Say, each node sends 512 bytes of data each second for each TCP connection (useful data if there are any or random stuff if not). Sure, this is basically a hard limit for bandwidth per connection, but if bandwidth requirements are not high, this might work well against traffic shaping analysis while also keeping latency reasonably low (1second*number_of_hops in the worst case scenario). Also this way it should be easier to reason about performance characteristics, since there is a hard upper limit. Number of connections can also be limited in order to limit total bandwidth utilization. Sincerely, Nazar Mokrynskyi github.com/nazar-pc _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
