On Thu, 15 Feb 2018 00:39:07 +0000, "Wessels, Duane via rssac-caucus" wrote:
On Feb 14, 2018, at 4:35 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Feb 14, 2018, at 4:22 PM, Wessels, Duane <dwessels@verisign.com> wrote:
It is meant to show (to me at least) that it actually works as described.
I knew cryptopan is prefix-preserving, but before this exercise I didn't realize it actually keeps addresses in their RFC791-era classes (A,B,C,D,E). That is, a class C input address remains in class C in the output, etc.
That surprises me, and might indicate an error in the implementation. Every bit in the input is supposed to be mixed evenly, and it sounds like at least the first set of bits in that implementation is not.
Maybe its something specific to dnsanon, rather than cryptopan, but it is intentional. See the start of scramble_ip4() in scramble_crypt.c.
That code is specific to dnsanon. I have mixed feelings about the dnsanon implementation---that feature, for example, seems like unnecessary complexity. -John