[LEAPSECS] Bulletin C and all that

[Zefram]

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 <zefram at fysh.org> 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