Rob Seaman wrote: >I'm very much enjoying the dueling perl / python and CRC / SHA competition >here :-)
Perl vs Python is of no significance. I use Perl for my example code merely because it's more familiar to me; the same algorithms can be coded either way. CRC vs SHA is of slightly greater significance (see below). >On Feb 10, 2015, at 9:45 AM, Zefram <[email protected]> wrote: >> I think it's a safe bet that AAAA lookups >> will be commonly available before we exceed the 16-bit range. > >One hopes, but the A lookups would then already be in the field. The way to deal with that is to also have an AAAA encoding from day one. The AAAA encoding can trivially have a much bigger range, such as 32 bits for offset. Applications using the A encoding would be more common initially, but as IPv6 progressively comes to predominate applications will probably naturally switch to the AAAA encoding. It'll largely be a function of which version of IP an application author is more familiar with, in cases where it's not dictated by the facilities of a particular platform. By the time the A format runs out of range, IPv4 should be thoroughly dead, and the A RRtype a historical curio that one would never seek out by default. >The main benefit realized here is of 12-bits versus 8-bits. The fraction >of false positives will be identical overall for 8-bits of this versus >8-bits of pseudorandom that. Given random distractor data, yes. My concern is more about the risk of colliding with some other protocol. A CRC is relatively likely to be selected independently by someone else trying to encode non-address data in A records, or by virtue of the linear structure to arise by accident from bitwise processing of addresses. A ones-complement checksum is similarly linear and relatively non-arbitrary. Hence: >> same encoding as I suggested for DTAI but using a different magic number in >> the check field computation. > >I like that gimmick. Any comments on how you selected the magic number? >Is the value you used well known? The magic number is meant to be specific to this protocol, never used anywhere else. Cryptographically its role is almost as a MAC key (except not secret), and the intent is that the strings that get fed to SHA-1 should not be strings that would arise for any other reason. I got the specific number from /dev/random, today. It's not a purely uniform selection from the 64-bit string space: I applied some limitation of the keyspace to avoid it looking like text or naturally-occurring data. You can find the generator program I used (mkmagic) and an essay that I wrote about magic numbers at <https://www.fysh.org/~zefram/magic/>. The essay explains the selection criteria. -zefram _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
