Hello HOPR Developers!
I was going through your implementation of the Sphinx packet and spotted that you are vulnerable to the attack presented recently by Khun et. al. (explained here: https://arxiv.org/pdf/1910.13772.pdf).
TL;DR the fact that in the most inner layer of the header encryption you use zero-padding (https://github.com/hoprnet/hopr-core/blob/master/src/packet/header/createHeader.js#L117) allows the last node to infer information about the path length the packet traveled, and hence decrease the packet’s anonymity. This can be easily fixed by using random padding, instead of only-zeros padding.
Thank you Ania!
Yes, we're aware of this limitation and your recent blog summarized the issue very nicely :)
We will get to this as soon as the currently ongoing refactoring is merged.
Hello HOPR Developers! I was going through your implementation of the Sphinx packet and spotted that you are vulnerable to the attack presented recently by Khun et. al. (explained here: https://arxiv.org/pdf/1910.13772.pdf).
TL;DR the fact that in the most inner layer of the header encryption you use zero-padding (https://github.com/hoprnet/hopr-core/blob/master/src/packet/header/createHeader.js#L117) allows the last node to infer information about the path length the packet traveled, and hence decrease the packet’s anonymity. This can be easily fixed by using random padding, instead of only-zeros padding.