Earlier you claimed this was "absolute proof", and that's the problem.

Yep. A proof would require a demonstration, that they actually extracted data from a phone, which was protected by a password with more entropy than can be brute forced. Moreover, it would not be sufficient that somebody said, they did it. There need to be multiple credible sources indicating, Apple has decrypted phones protected by strong passwords. Without that, it couldn't be considered proof.

76% efficiency (24% waste) is for 1 cell i assume for 20 cells it would be 1.2% waste ( 98.8% efficiency)?

What sort of construction reduce waste by adding cells?

with the on die regulator, won't that area of the chip be a tad warmer than the rest of the chip, or will the heat be a moot point?

The summary says 76% efficiency. That would mean 24% of the energy you put into the chip is turned into heat by the voltage regulator. Sounds like a valid concern to me.

Since the default passcode is only 4 digits I would expect about 99% of users to be brute forcible in a few seconds to someone with the capability to image the device and identify the key storage block.

Sounds plausible. Someone in this thread said the number of iterations in the computation needed to get the key was chosen such that it takes 100ms for the phone. If we guess it can be done 10 times faster on a computer, it takes about a couple of minutes to try all 4 digit combinations. That is fast enough, that you wouldn't even bother with submitting it to a computing cluster.

A 4 digit pin is not completely worthless in scenarios, where limiting the number of attempts is possible. But once the pin can be attacked off-line, you need a lot more digits to justify the time spent implementing the encryption in the first place.

I don't know about the iPhone but Android lets you enter a password for encryption, not just a PIN.

If you were to go from just digits to alphanumeric characters you could reduce the number needed from 39 to 25 or even only 22, if it was case sensitive. But entering case sensitive passwords on a touch screen is annoying. So it would be much more convenient to enter the 25 characters needed to avoid that requirement. But seriously, typing such a long password is hard to get right every time, even if you are using a keyboard. Those small on screen keyboards do increase the error rate.

On my computer I do use a password with 130 bits of entropy. I made the password a bit longer than strictly needed, such that I could throw in a bit of error correcting code. That way a typo or two in the password doesn't prevent it from being recognized. It does mean I have 32 characters to type though, but typing 32 characters, where a couple of typos are allowed, seems easier than typing 22 where no errors are allowed.

I don't see myself using anything like that on my phone.

Apple claims that it uses AES with a 128 bit key, so if they can unlock it that quickly they MUST have a backdoor to the encryption key.

The input provided by the legitimate user for decrypting the content has way less than 128 bits of entropy. So they just need to brute force that input. What Apple can do, which the forensics people might not know how to do, is to extract the encrypted data and put it on a computer, where brute forcing can happen without each input having to be entered through a touch screen. Any security one might think this adds, is nothing but security-through-obscurity. Real security of the encryption could only be achieved by the user entering some sort of password with sufficient entropy. A 39 digit pin code would be sufficient to make AES be the weakest point. But would anybody use a 39 digit pin on their phone? Anything less would make the pin be easier to brute force than AES.

You can shift the balance a bit by iterating the calculation which produces a key from the pin code. A million iterations would probably be acceptable from a user experience perspective, but that would only reduce the required number of digits from 39 to 33. A milliard iterations would not be good for the user experience, since they now have to wait quite some time after entering a pin. And with the pin still needing to be 30 digits in length, they'll often need to re-enter it multiple times, before they get it right.

and those people outside can't do anything useful with the IP that they have.

Might this mean we'd soon see an identd variant designed for helping with this issue?

they used to (ab)use customers on open internet connections to provide this service but nowadays I belive they provide it from their own servers

Not sure what they are doing these days. Their old scheme was a major contributing factor in a huge Skype outage a few years back. As far as I recall, they needed a bunch of servers at Amazon in order to get Skype back online. That outage might never have happened, if IPv6 had been deployed when it should have been.

And there are millions of packets going by on the Internet. Just think, if every other packet were concatenated on the previous one, there would be half as many packets, and that would double the capacity of the routers.

This only helps as long as the processing power on the router is the bottleneck. As soon as packets are large enough, the actually link bandwidth will be the bottleneck. At that point fewer larger packets will not give you more throughput.

As links become faster the optimal packet size will also increase. There is a huge difference between dialup and 100Gbit/s fiber. You wouldn't want the same size of packets on both kinds of link. A 1500 byte packet would block a dialup link for long enough to cause a measurable latency increase for any small packet you might want to send through at higher priority. You don't want packets that large on dialup. But on 100Gbit/s fiber such a packet size would mean millions of packets per second. You'd want larger packets, such that you don't need to handle millions of packets per second.

But what about those packets, which go over links of different types? With IPv4 they could be large as they were sent and be split into smaller fragments on their way to the destination, and then be reassembled at their final destination. But having this work done by routers on the path adds to the processing cost for that router, and that processing cost is what we want to reduce in the first place. For that reason this was changed in IPv6. Routers no longer fragment packets in transit. A packet is the same size all the way from the source to the destination.

Assembling multiple fragments into one packet is even more work and was never done by intermediate routers. (Some firewalls might do it before deciding whether to forward or drop the packet, but that was never intended by the standard.) Grouping unrelated packets would be even more difficult. And as long as it is only done end-to-end, it can only be done if they have the same source and destination anyway. There is no standard for doing this.

But for traffic that would get segmented by TCP or fragmented by IP, we really do want to have the packets on the wire get larger as link speeds increase. In fact the maximum size was increased between IPv4 and IPv6. It used to be 64KB but has been increased to 4GB. Hardware that would allow us to benefit from that increase is still difficult to come by (if it even exists), but IPv6 is designed to be usable in many years, so it makes sense to support larger packets.

Yeah, then we came up with CIDR. Then we widely implemented NAT as a stopgap.

CIDR was a great stopgap. NAT was not.

Without CIDR the addresses would have run out faster than any solution could have been implemented. CIDR was not that big a change, so it didn't break lots of stuff. And it slowed down the consumption of addresses a lot. If a decent effort had been put into upgrading to IPv6, it could have been completed before addresses ran out, even if CIDR had been the only stopgap measure, and NAT had never been invented.

But NAT got widely deployed. Not because real scarcity of IPv4 addresses, but rather because of an artificial scarcity. ISPs were charging for IP addresses, so with NAT already available, private users used that to avoid paying extra. It did slow down IPv4 consumption so much, that ISPs decided not to work on deploying IPv6. But a major reason for the deployment not happening faster actually was that there was no competitive advantage.

The ISP which deploys IPv6 has some expenses in doing so. If they decide to save that money, they are causing a problem. But the problem they cause affects the entire industry, so it was not a competitive disadvantage. Moreover the lack of IPv6 deployment is now causing more problems for newcomers than it is for those established companies, who were responsible for the problem in the first place. And this is the real reason we have such a mess today.

Rationing of IPv4 addresses was a great idea. It just happened way too late. Rationing once you have consumed 98% of a resource is not solving the main problem. The 1024 IPv4 addresses an ISP can get if they start deploying IPv6 is not that great an incentive.

At the time CIDR was introduced a rationing policy should have been agreed upon. As soon as IPv6 implementations were reasonably mature, but not widely deployed, rationing should have been applied to keep the base of IPv4 only systems constant. At that point ISPs should only have been able to get new IPv4 addresses for use in dual-stack deployments. If they used the newly allocated IPv4 addresses for IPv4 only deployments, they should have received no more IPv4 addresses until they had converted enough IPv4 only systems to dual stack.

A proper rationing policy would have ensured by the time IPv4 addresses ran out, there would be at least as many dual stack deployments as IPv4 only deployments. That would make IPv6 only look much more viable, and it wouldn't take a lot of IPv6 only systems to make dual stack look preferable to IPv4 only, if dual stack was proven to work in practice.

It is too late to implement such a policy now. So we will have to find another way out of this mess. It was clear already a decade ago, that there simply didn't exist the right economic incentives for ISPs to deploy IPv6. And nobody in place to implement the needed policy, had the balls to do it. That IPv4 addresses ran out without IPv6 having reached a significant deployment should not have come as a surprise to anybody. That ISPs still believe IPv4 only is the best strategy even now, is however a bit surprising, and quite scary.

NAT was part of the reason it took such a long time to reach the point we are at now. And what good has it done us? It delayed the inevitable. But that extra time was not used to make us more prepared for it, as such we didn't get any benefit from NAT, which we can use to ease the deployment of IPv6. Also the delay has meant the network is now larger, which means more work and more expensive to upgrade, than it would have been, had it happened earlier. NAT also made the network more complicated, and many of the blockers in deploying IPv6 are due to problems caused by NAT. Moreover many people have gotten so used to NAT, they don't know how the Internet was supposed to work. And now they don't want IPv6 because it doesn't look like what they are used to. Lots of effort has been put into developing workarounds for the problems introduced by NAT. And none of them work great. All of that wasted effort would have been much better spent on getting IPv6 deployed in the first place.

There is just no way anyone isn't at least a avid slashdot reader in terms of techniess is going to be able to be on an ipv6 only endpoint

You won't see many IPv6 only users on slashdot either. I'm wondering if I should change my signature to read "slashdot is part of the problem" until they eventually set up AAAA records for slashdot.

You could have a DNS server that generates synthetic AAAA records from the ipv4 A records and predefined prefix that routes to the NAT.

64:ff9b::/96 is allocated for exactly that purpose. And BIND has support for synthesising the AAAA records. But I don't see much benefit from such a deployment compared to dual stack plus CGN.

Its going to make inspects and higher level protocol address rewrites pretty complex for the gateway. Think something like h.323 with the host address. You can't just swap out 6 bytes worth of src/port you going to have to completely re-craft that packet's content.

Exactly, that is a real challenge. And for that reason I think CGN + dual stack is more viable in some situations. Deploying CGN without dual stack is just screwing over the customers.

Your issue should only occur for a site that claims to be available on IPv6 and isn't.

There are plenty of those sites around. But what you see even more are sites, which are available on IPv6, but are quite unreliable on IPv6. A couple of high profile examples include YouTube and facebook, which are much more reliable if you are on an IPv4 only connection, than if you have dual stack.

One of the blocking factors that kept websites from deploying IPv6 in the first place was a problem on the client side with clients which thought they had IPv6 support, but in reality did not. This is similar to the problem you describe, but is different. An ISP should of course not deploy IPv6 to their customers if they aren't going to have real connectivity to the IPv6 backbone. But as RFC 6598 addresses start seeing more use, there will be routes thinking they can use 2002:6440::/26 6to4 address space. Those clients will then think they have IPv6 connectivity, but won't be able to reach dual stack sites.

An ISP can actually avoid that particular problem by deploying native IPv6 to their customers. Once there is native IPv6, the routers won't bring up 6to4. That way you can avoid 6to4, which has been broken by RFC 6598.

IANA has recently reserved the IP block 100.64.0.0/10 for use with carrier grade NAT.

That's interesting. I didn't know about that block. I'll keep that in mind as I might get involved with deployments, where this is applicable. I looked up the relevant RFC, which is RFC 6598. I find it interesting that this was taken out of ARIN address space. With ARIN being next in line to run out, this block must have accelerated depletion for ARIN.

That there is a /10 allocated for the purpose doesn't necessarily mean there will be millions of users behind a single CGN. A medium sized ISP could use this /10 to assign one address to each customer without having duplicated addresses within their own network, even if they plan to deploy multiple CGN devices to service their customers. That way customers of that ISP can communicate with each other as well as the ISPs own servers without going through CGN. It can also make management easier.

I am curious what this means for usage of 2002:6440::/26 address space. Things could get interested. This is briefly covered in section 5.2.6 of the RFC.

Wouldn't Google have to block Win 8 completely?

More likely they'll just insert ads directly into the video stream. Sending ads as a separate video stream makes them quite easy to remove. But no doubt Google would be able to produce a new stream containing both ad and content. That won't stop downloading the video, but the downloaded version would include the ad.

Any artificial limitation, which puts somebody else's economic interests ahead of the interests of the owner of the device, should not have been legal in the first place.

A digital camera, which cannot store more than 30 pictures on a 128MB storage card when using the best quality setting is a limitation which exists for a good technical reason. Such a limitation is not artificial, and thus shouldn't be outlawed. But a digital camera that can only take panorama photos as long as they are stored on a storage card bought from the same vendor and not if the storage card was bought from a different vendor is an artificial limitation, which does not benefit the owner of the camera in any way. It must surely have been a little bit of extra work to implement the limitation in the first place, which is what characterizes artificial limitations.

Limitations which are there for safety reasons or to improve durability of the device are fine. For example storage media have extra capacity to compensate for imperfections in the media. That the logical capacity is less than the physical capacity is in the owner's interest, because otherwise the lifetime of the device would be significantly reduced. (It is also in the vendor's interest in order to reduce RMA cases. In some countries vendor's are subject to a minimum two year warranty.)