afaik the "right kind of code" does a lot of heavy lifting for practical implementations, such as Classical McEliece.
correct me if I am wrong as I havent spent much time looking into it, but the security analysis essentially says "we assume the Goppa code is indistinguishable from a random code so the best attack is to do generic decoding for a random code (NP-hard problem)". but there is no reduction to some NP-hard problem that Goppa code (the specific code used in Classical McEliece) is indistinguishable.
the assumption is reasonable as nobody has been able to find a distinguisher for decades. also, if a distinguisher exists, it also doesn't translate into a direct attack against the system, it just means you cannot rule out "structural attacks" and jump to NP-hard problem.
Yeah that's right, there are no known cryptosystems whose security is based on the difficulty of solving an NP-hard problem. It's not known even in theory whether P != NP implies that one-way functions exist: for example, it might be that all NP problems are easy on average, or that there are problems that are hard on average but that you can't sample the problems and their solution at the same time.
(And this is even with the simplification that polytime = practical and not-polytime = infeasible.)
> It's not known even in theory whether P != NP implies that one-way functions exist: for example, it might be that all NP problems are easy on average, or that there are problems that are hard on average but that you can't sample the problems and their solution at the same time.
Relevant paper:
Impagliazzo, R. A personal view of average-case complexity theory. In Proceedings of the 10th Annual Conference on Structure in Complexity Theory. IEEE Computer Society Press (1995), 134–147.
OK, hoarding discovered zero-days might not be the best strategy, BUT if we actually create a backdoor and don't tell anyone about it, then this should be safer right? right? /s
1) length is never updated so while is infinite loop (if length is not 0)
2) the first character is never output since at address 0 (assuming X=0 at the start) is the value length but then the pointer is incremented twice so the first print *address prints the character at address 2?
if I am mistaken I'd be happy if someone explained why it makes sense
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 :`).
correct me if I am wrong as I havent spent much time looking into it, but the security analysis essentially says "we assume the Goppa code is indistinguishable from a random code so the best attack is to do generic decoding for a random code (NP-hard problem)". but there is no reduction to some NP-hard problem that Goppa code (the specific code used in Classical McEliece) is indistinguishable.
the assumption is reasonable as nobody has been able to find a distinguisher for decades. also, if a distinguisher exists, it also doesn't translate into a direct attack against the system, it just means you cannot rule out "structural attacks" and jump to NP-hard problem.