RE: Advantages and disadvantages of using CB64 type of identifiers

> My understanding is that SeND chose different IIDs for different
prefixes
> but that might be overkill. If the IID is not a function of the prefix
> it would enable redirection by a resourceful attacker
> by precomputing 2^64 public/private keys that hash to all 2^64 IIDs.
> If the content of the packets are encrypted the redirection would not
> provide access to the content; it could only be used for DoS or for
> gathering the content for cryptoanalysis.

There are two issues: catalog attacks and privacy implications. I have
already expressed my reservations about the privacy effects of having
unique identifiers in addresses. I would certainly not recommend that my
company ships anything like that.

> A while back Jari Arkko computed the amount of space needed to store
> 2^64 precomputed keys, and the storage space was a few buildings the
size
> of the former world trade center buildings I think.

You do not need to compute 2^64 keys to start having an effect. Suppose
that there are N users in the system, and that the bad guys have
computed a catalog of M keys. The average number of hits that a catalog
of size N will achieve is approximately NxM/2^64. There are currently at
least 500M Internet users, it is reasonable to expect some growth, so we
can set N to about 1 billion -- 2^30. This means you need M=2^34 to get
at least one hit. That is probably less than a Terabyte of data, i.e.
pretty soon a single hard disk.

Everybody should be convinced that, when it comes to cryptography, 2^64
is actually a small number. SEND alleviates this risk by
cryptographically link a public key to the entire 128 bits of the
address. This is NOT overkill.

-- Christian Huitema