However, the number of 2048-bit primes is so astronomically large (think ~10^600), that you're more likely to randomly guess the prime factors of a given key than you are to find a collision between any two RSA-4096 keys ever generated -- past, present, or future.

Actually that's not correct. Where you say more likely, you should instead have said slightly less likely. But that is assuming the key generation algorithm generated random primes. In reality the primes being generated are not truly random. And that flaw in how the keys are generated is the whole point of the article.

The second point of the article is that you don't need to fully understand the flaw in order to exploit it. They had a hunch and tried it out. Computing GCD between every pair of keys is the obvious approach, but I would have thought that would be infeasible due to the extremely large number of pairs to be considered. And they did in fact make some optimizations in order to speed up the computation. It does look like their algorithm is still quadratic time in the number of keys, but it may have smaller complexity with respect to the key size.

Managing to identify all the repeated primes is quite impressive.

Once you have identified that the problem is real, and which devices are affected, a determined attacker could try to identify all the primes that could be generated by that class of device. You actually just need the first of the two primes. As explained in the article the first prime tend to be less random, and knowing one of the two, you can compute the other.

Others will get the wrong end of the stick- even if you found the hoed through innocent means- assume that you hacked or were trying to hack into their system, and act accordingly.

And those companies are causing an unnecessary risk to all the reasonable companies. I think for the majority of people, the first reaction when finding a security hole is to find out how to contact the persons responsible for it in order to get it fixed. How many times will a person do that if the reaction is either being ignored or being threatened with a lawsuit? I don't think many people will keep being helpful if that gets them such threats, and I think most people will stop the first time when they get such a threat.

So some people will just start ignoring the security holes, and others will start thinking about other ways that knowledge could be used. Some of those may come up with various sorts of abuse as the other way it could be used. If reports about security holes were handled in a reasonable fashion by the majority of companies and never resulted in threats against the person who reported it, then there would have been an overwhelming chance that it would be found by an honest person and reported before it was found by somebody wishing to abuse it. But those unreasonable companies are keeping most of the honest people silent and turning the rest to think in a less honest way. They are increasing the risk to the entire industry.

I'm curious how the case would turn out in court if a security hole was found in a completely innocent way, and the person who found it decided to publish details on the security hole after the irresponsible company had tried to threaten that person to silence because they didn't want to spend resources on fixing their stuff.

Another method of protecting against physical theft of the HDD and passphrase guessing is to utilize online cloud-based services for key distribution.

I'll me propose an actual API that could be used for this. First of all the master key is encrypted with two layers of encryption. First it is encrypted using RSA, next it is encrypted again using the password. The RSA encryption step needs a bit of extra work to make the encryption indistinguishable from a sequence of random bits. By default an RSA encryption doesn't look exactly like random bits. The point is that the RSA encryption is from an interval [0;n[, where n is the product of two large primes. Since n is not a power of two, not all possible combinations of the bits will result in a value in that interval. But after performing an RSA encryption you can just add a random multiple of n to the value, and that essentially solves that part. Once you have made that minor step between encrypting using RSA and encrypting using password, it will be such that no matter which password you try, you cannot know if that password was correct until you have done the RSA decryption as well. The RSA secret key is on the server, the RSA public key is stored in clear on the encrypted disk.

Decryption happens using this protocol:

1. Key material is decrypted using the password, which was entered.
2. Client choose a random blinding value to hide the real secret from the server.
3. Client sends a request to the server for RSA decryption.
4. Client use the RSA public key to validate response from server. If invalid, it keeps trying until it receives correct decryption.
5. Once client has correct decryption it opens the encrypted filesystem.
6. Client finds an HMAC key inside the encrypted volume and computes an HMAC of the request it sent to the server.
7. Client sends HMAC to the server to prove that the request the server handled previously unlocked the filesystem.

The HMAC key is completely unrelated to the actual encryption key. The server knows the RSA secret key and the HMAC key. All the server will ever know was that a request was made and if the validity of the request was subsequently proven to be valid. The server learns nothing about the key material. As a matter of fact, a completely valid session of this protocol could be produced using only the key material on the server.

If MIT were to choose to turn, say, 18.128.x.x over to ARIN, they'd have to completely reconfigure their network

True. If they were to return any addresses at all, they can no longer announce a route to 18.0.0.0/8. (I don't know if they do announce it like that, but having a class A, they could). If they can no longer announce a /8 they would have to announce smaller blocks. If they were able to squeeze everything into half the addresses they have now, then they could announce a /9 and return the other /9. If that is not possible, then they would be forced to announce their addresses as multiple prefixes and thereby increase the global routing table size and cause problems for everybody else.

If you have a /8 and would want to return some, you shouldn't do so unless you really think it is feasible to squeeze all your usage into half the space you used to have. You also need to ensure that whatever address space you are left with is enough to last until everybody else have switch to dual stack (or IPv6 only). Since the purpose of returning addresses is to prolong the transition (which isn't much of a useful purpose), it also implies that the more addresses you return, the longer those you have left will have to last. That's not much of an incentive to return addresses.

Apart from BGP is it really much of a problem to return just small fragments of address space? Do you have to change your network, if you weren't using those addresses anyway? The answer to that question of course is yes. If you were to just change your BGP announcements to stop announcing some addresses that you weren't using anyway, nothing would break yet. However if you were to return them and they got reassigned, things would break, if you had only changed your BGP announcements.

The reason things would break is that the route to those addresses would still end up somewhere inside the same network, if it originated there. Taking your example, a packet from 18.127.1.2 to 18.128.2.3 would never leave the MIT network even if the destination address had been returned, because the routers inside the MIT network would still think it was a destination within their network. It would propagate through their network until a point where some router would report no route to host. So both the BGP announcements and the routing inside the network would have to be redone before addresses could be returned.

It would make more sense for them to set up a brand new IPv6 network, slowly migrate everything there, and once it's all done and if they don't need IPv4 anymore, they can then turn the entire 18.x.x.x back to ARIN.

Even once they have everything set up as dual stack, they would still want to keep IPv4 for as long as there was anybody else on IPv4 only who they wanted to communicate with. The point at which it makes sense to return the IPv4 addresses to ARIN is also the point at which nobody else would want them anymore. It is not like the demand for IPv4 addresses would drop to zero overnight, but it is probably going to be close to it.

Most likely we will eventually reach a point where nobody would bother to setup new IPv4 networks, and the demand for addresses will decrease. The decrease in demand will not be very visible since there won't be much of a supply either. But those who are already dual stack won't turn down their IPv4 support right away. Just as their isn't much to gain from turning up IPv4 when everybody else is dual stack, there won't be much to gain from turning down IPv4 support.

At a later date the work to keep administrating IPv4 in parallel with IPv6 will be more significant than the work it will take to remove the last few IPv4 dependencies. At that point people will turn down IPv4 and return the addresses. And nobody will care about the returned addresses.

It's true that the initial allocation of IPv4 addresses was badly done

Effectively the original addressing architecture capped the achievable HD ratio somewhere around 75%. Nowadays we are doing 80-90% with more administrative overhead. The bad decision was not so much the addressing architecture, it was the limited size of the addresses. A 64 bit address with a 60-70% HD ratio would have allowed for more hosts than a 32 bit address with a 90% HD ratio.

The proper design is to figure out how high you want to push the HD ratio (with the knowledge that administration becomes a burden if you try to push it over 80%) and how many devices you want to support, and then with those two numbers in mind compute the required address size and design an addressing architecture to match it. Of course we shouldn't blame the people who designed it at the time. They didn't know then what we know today. The entire research on HD ratios is more recent than the design of IPv4.

IPv6 addressing architecture was designed for an HD ratio of 80% on bit positions 3-47, and a much lower HD ratio on bit positions 48-127. But overall it will most likely allow for more devices than this planet can sustain.

if anybody tries accessing them from IPv4-only nodes, they should be redirected to ipv4.google.com, ipv4.facebook.com

That is not the way forward either. Such a redirect would work for all those people that don't need it, and it would fail for those people that do need it.

The main domain should be available over both IPv4 and IPv6. Each client use whatever it has. The problem with that is that some networks are misconfigured, and some software doesn't do fall back to another protocol very well.

ipv4.google.com already exists for those people who have a misconfigured connection. I think it was set up prior to IPv6 day last year, and it will probably stay around for many years to come. But a redirection like you suggest won't work for those people with a broken connection because you cannot send a redirect back to a client that is unable to contact the server in the first place. For the majority of users where things just work that redirect would work, but it wouldn't be desired. The goal is for the transition to happen with the majority of the users never noticing a difference. A period where all IPv4 only users get redirected to a different domain doesn't achieve that.

Had clients that defaults to IPv6 had good fallback to IPv4 to begin with, then we wouldn't have had the need for separate domains, redirects, DNS whitelists, IPv6 day, etc. We would have seen content available over IPv6 2-3 years earlier than we do now.

Nothing like having a really long download session abort because Windows spontaneously canged your IPv6 local address.

I don't use Windows, so I didn't know about that bug. But I would say Microsoft should go and fix that bug. And if Microsoft won't fix that bug, then you should consider using a different operating system, that doesn't suffer from said bug.

The correct implementation of privacy extension would by default do the following: At system boot each interface is assigned two link local addresses as well as two IPv6 addresses per router advertised on that network segment. One of the two addresses would be based on the MAC address and hence be static, the other address would be randomly generated (according to the spec). Incoming connections can use any of the IP addresses. Outgoing connections will use the randomly generated address (unless the application explicitly overrides that choice by binding to a different address). Every 24 hours more randomly generated addresses are added, again one link local address per interface plus one per router advertised on that network segment. The new randomly generated addresses are made default. The old randomly generated addresses remain on the interface until they are no longer in use, and only then they are removed.

If Windows didn't suffer from the bug you mentioned, then it would notice that there was an open TCP connection using that old address and thus would keep it on the interface even though it wasn't the default for new outgoing connections anymore.

And when I said that the above should be the default, it should of course allow the user to configure it. For example the 24 hour interval could be configurable. In addition there is a few possible tweaks. For example you might not need privacy extension on link local addresses. It will be of limited use since for a link local connection the other endpoint can see the MAC adress anyway. In addition the 24 hour interval could be made in a way that doesn't synchronize the adding of new addresses. If you have two interfaces and receive two prefixes on each of those there is no need to update all four addresses at the same time. Doing it at the same time might reveal some information to the peers you are communicating with, and it will also reveal information about your uptime. Instead the first assigned address is given a lifetime chosen uniformly between 1s and 24h. After that it is updated every 24h.

But what I got was this... ...the run rate is such that if we reclaim ALL IPv4 address space, including yours and mine that we're using right now, we still run out in 2019.

I tried to do similar calculations a little while back and came up with 2020 as the time we would run out. So I think your calculations are right, the one year difference just means a bit of uncertainty. Another way to interpret the result of this calculation is that by 2019 there will be more devices on IPv6 only than the total number of devices that will fit in IPv4.

Some DNS servers are completely broken and drop requests for an AAAA record. If your local caching DNS server is doing this then you basically end up seeing all web requests, etc. being slow since the browser will look up an AAAA record to find out if the website is accessible over v6 and the DNS server won't respond.

Some DNS servers are worse than that. They will not only fail to lookup the AAAA record, but in the process of attempting, they will put garbage into their cache and cause subsequent A lookups for the same domain to return an incorrect IP address.

If you bother to look at the consumption rate you'd realise that even if all of these addresses were returned to the pool they would buy a few weeks and then we'd be right back where we started.

They may have lasted two months if they were returned a year ago. But if they were returned today, they would be consumed as quickly as APNIC could file a request. Extrapolating the usage trend in the APNIC region from before the pool ran out suggests that they by now could file a request for 10 /8 networks to meet actual demand.

We are well past the point where returning addresses will do any good. They will be consumed just as quickly as they are returned, and doing so will fragment allocations even more leading to an explosion in the routing table size.

Those who actually have unused addresses, which they could return have a few options:

• They can return the addresses, which will allow somebody else to postpone the work they need to do by a couple of weeks, but does nothing to solve any problems.
• They can try to figure out when the market price on IPv4 addresses peaks and try to sell them for monetary gain.
• They can act in the best common interest and hold onto the addresses until they find a way those address could be used to ease the transition from IPv4 to IPv6 for everybody.

by my count the direct /8 allocations compose about 700 million addresses.

But most likely only a few million of those could be returned.