> But I'm not sure if it works the same way against elliptic curves - or at least you'd probably need a bigger computer to attack the same level of security.
Elliptic curve cryptography is also based on the difficulty of computing discrete logarithms, which makes it vulnerable to Shor’s algorithm. Unfortunately, while the increased difficulty of brute forcing ECC with a classical computer allowed it to use smaller key sizes to achieve security equivalent to older algorithms like RSA, the smaller key sizes make ECC attackable with fewer qubits.
Yes, that's correct -- I'm in the USA, and not in Europe or Africa. What is your point with this? ARIN has, of course, delegated my assigned IPv6 network to my ISP; you do realize that this is SOP for ARIN?
The point was a prefix from 2600::/16 isn’t special; it’s just from one of the blocks assigned to ARIN. One ISP I know of with an allocation in that range is Verizon, which announces a number of prefixes over BGP in 2600:1000::/24
Uhm, anyone with an ISP in the United States is going to have a block delegated from ARIN. That's the whole point of ARIN, isn't it? Nothing they delegate is inherently special, because ARIN administers all of the allocations for their region.
I'm saying that perhaps the 2600::/16 delegation is especially reserved for a certain class of user in order to tag us as something. Surely, my own ISP holds more delegations than that slice alone. It's certainly standing out like a sore thumb to anyone analyzing logs. As I said, it can't be merely a coincidence.
Interestingly, I also subscribe to mobile voice/data service from the same ISP, and activating mobile data here at home gives me, sure enough, another 2600::* delegation.
There’s a great book about the development of Cell and Xenon (which went into the Xbox 360) called “The Race for a New Game Machine” that was co-written by a couple folks who worked on them at IBM.
The use of IPv6 in cellular devices is specified by RFC 7066. When a device first registers for a data connection, the network provides an interface identifier to use for the lifetime of the registration, which is guaranteed not to conflict with the one used by the router. The network also allocates a /64 prefix exclusively for use by the device. These two things allows the device to perform SLAAC for link-local and routable addresses without needing to do duplicate address detection.
It’s also worth mentioning SLAAC does not strictly require a hardware address to function. For example, Apple devices implement newer standards from IETF to generate random but stable addresses that don’t reveal information about the hardware addresses (https://support.apple.com/guide/security/ipv6-security-seccb...)
> Radio firmware and state machines have always had weird bugs, and even when it conforms to standards (some of which are extremely interpretable), does very weird things in the real world. Pre-smartphone, being able to update phone and radio firmware was extremely rare, so it was common for the networks instead to implement workarounds on a manufacturer or handset basis. Having a hardware ID that identified this was extremely useful
Now that it’s common for devices to be updated regularly, they will typically send an extended form of the IMEI to the network called the IMEISV, which is the same as the IMEI except the final check digit is replaced with a two-digit code indicating the current software version (SV = Software Version).
Probably not a lot. It needs to have a fixed length on the wire, and having 100 updates to the radio firmware for any given model of handset... not likely?
You’re right that the signals have to be converted back into bits at the destination. Basically, this solves the problem of pumping those bits at high speed across traces on a circuit board vs within a chip. The longer a signal has to go, the harder it is to maintain its integrity.
