well, it depends on the size of the quantum computer. of course you can make large enough RSA keys (depends whats your security margin/assumptions) but the problem is that the size/computational increase is exponential whereas the solving speed scales polynomially.
The size/computational complexity of usage also only grows as a polynomial with RSA. But even with this in mind, a quantum computer that can crack in polynomial time is still problematic. While you can increase the key size, the operator of the quantum computer could enlarge his computer, a true cat-and-mouse game. Unlike the current situation where usage complexity grows as a polynomial, while cracking grows exponentially. This difference is the reason why we can pick key sizes where signing/decryption takes a millisecond while cracking it takes (presumably) billions of years.
Encountering this by chance is exceedingly unlikely of course, if p and q are randomly generated. In probability terms it amounts to the first half of p (or q) all being zero (apart from a leading 1) so roughly 2^(-n/4) where n is the bit size of n. So for RSA 2048 the probability of this happening is on the order of 2^-512, or in base-10 terms 0.0000000...0000001, with roughly 150 zeros before the one!
It may be a combination of making the battery overheat which would trigger the planted explosives from a supply chain attack. Of course, I am no hardware engineer/bomb expert to know if that is possible.
Well that depends on the binding right? In case you use the "artifact binding" then theres also direct communication between SP and IdP. I havent seen it in the wild and I am also no professional, but I saw it in the 2.0 standard, e.g., see https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-...
I watched the TC interview with Durov (Telegram) and apart from it being a big Telegram ad what struck me is that he told a story about his employee being approached by "an intelligence agency" and asked to reveal information about what open-source libraries they use.
It is kind of strange since their apps are supposed to be open source, maybe he meant the backend? Nonetheless, it seems this has been their modus operandi for a long time.
Remember that NSA is openly interested in systemd and how it works. It's a double edged sword. They wanted to be sure that it's hardened as they like it, and note any "useful features" that might come handy later.
The thing is, as computers proliferate and we start to use them in more places, the effects of possible holes moves closer to our homes. From distant infra to near infra; from borderlines to our homes and transportation we use everyday. Even to our pockets via smartphones and other smart devices we host in our homes.
These solutions are not perfect and typically stop working after a certain time because they patch it/unintentionally break it.
The only reliable solution I found is to VPN to some non-western country where they typically don't have advertisers. Of course, this brings a load of other issues :`).
Another interesting thing regarding the ECC is they use Ed448, compared to something conventional like ECDSA with P-256 or Ed25519, which is way slower (30x-ish slower verification):
At >400 operations per second, that doesn't explain most of the 2/second (500ms) operations the discoverer apparently observed. Were they running on an old Pi and you on a currently high-end CPU or so? Basically, what hardware is this benchmark on?
I mean it highly depends on the CPU so I only posted it to show the relative slowdown compared to ECDSA. I ran this on my free tier Google Cloud server so it is not some super CPU.
However yes, even on this, not so powerful CPU, it doesnt take 500ms so I dont think it explains it.
Thanks! That indeed sounds like it rules this out as the reason why it was found.
Curious that asymmetric crypto isn't even the slow part here. Feels like they just messed up somewhere (but I don't have the low-level asm/C skills to check that without considerable time investment)
I am confused. What does happen after clicking allow? Does Apple just provide a password reset form to the person on the iForgot website or does it show up only on the device?
This (and Signal's solution as well) does not protect against active MITM attackers with quantum computers. They would need to incorporate post-quantum signatures into it as well.
The reason why it is missing (but seemingly planned in the future) is because it is not as critical as this change. This change prevents attackers from recording conversations now and decrypting them when (in the next ?? years/decades) they get access to an actually powerful quantum computer. On the other hand, you can do MITM only after you factorized RSA key (or solved discrete log).
The additional reason I presume is that this typically requires a change to the whole public key infrastructure (certificates, OCSP, etc.) which is a lot of additional work.
I'm a bit puzzled. Suppose you do single Kyber key exchange, and you then hash the shared secret with a domain separator to get a fingerprint, wouldn't that mean you now have a shared secret that you can verify wasn't under MITM.
You then can build post quantum future secrecy / key rotation on top of that, by mixing in new key material and it remains secure from MITM, as long as the internal state of the endpoint isn't compromised. The endpoint compromise is outside networked TCB threat model, as such compromise could also be used to exfiltrate long term post-quantum identity keys for undetectable MITM).
https://eprint.iacr.org/2017/351