You're joking right? You're proving the article's point. The social sciences have informed policymakers for decades. The US was founded by social scientists (as TFA defines them, the social sciences include philosophy and so on).
Physicists and mechanical engineers simply do not wield the same amount of power that computer scientists/software engineers do. FYI the article does not suggest literally putting CS in the social science department. TFA is just arguing that in light of how CS is applied in society, computer scientists need to be more broadly educated. I was a cryptography PhD student for awhile and I can tell you by-and-large CS academics are so far up the ivory tower it's a wonder they don't die of asphyxiation. To ignore the reality that algorithms, and those that design them, hold an enormous, and growing, amount of sociopolitical power is not just willfully moronic, it's arguably leading to the death of liberal democracy.
That's true that it's theoretically impossible, but you can get close by using verifiable computation protocols like Pinocchio to restrict the computations that the adversary can do. That is to say that before blindly accepting the result from the adversary and decrypting it, you first ensure that they performed a computation you specified beforehand.
It's a requirement of these algorithms that they run in polynomial time with respect to the size of the input. They're large polynomials with big constants, but they're dwarfed by the exponentials you're considering.
Not quite. The data is encrypted, the computation is not. Through the use of universal circuits (circuits that run other circuits) you could give an encrypted executable to an untrusted party to run on encrypted data, but note that the result of this computation is encrypted as well (so, the executable would be useless for the other party -- only you would be able to use the results). In fact, this idea underpins the crucial idea behind FHE: bootstrapping.
I did part of a PhD in this field; your comment about information leakage is not true. FHE schemes are IND-CPA secure, which means you can't test for equality in the encrypted space (Note that in the standard definition of homomorphic encryption, you're only guaranteed that Dec(Enc(x+y)) = Dec(Enc(x) + Enc(y)) = x + y). Your comment only applies to schemes where you can test for equality in the encrypted space, which are not IND-CPA secure and should never be used in practice (except in some extreme scenarios where you can/need to make some strong assumptions).
Gravity isn’t metricized (and it would be hard to do so), the best we can do at the moment is indirectly measure it via +/- or other stats like what SC30’s teammates’ true shooting percentages are with him on and off the floor.
To add to your post, lattice attacks (LLL/BKZ/etc) are becoming even more prevalent in cryptanalysis as they are the best known attacks against next-gen cryptosystems like NTRU, or anything based on the Learning-with-Errors problem, which includes schemes with "fun" properties like full P/poly homomorphism, attribute/predicate encryption, etc.
There's nothing inherently wrong with browser-based crypto. Most issues arise when you try to e.g. replace like TLS with JavaScript to encrypt passwords before sending them to a server. SHA256 doesn't become broken simply because it's run in a browser.
I'm not an expert on quantum algorithms, but if you're wondering what the implications of this are, here's what I understand as a cryptographer: a lot of post-quantum cryptography (i.e., not anything we use now like RSA or ECC) relies on the hardness of the closest vector problem (given a real-valued vector, what is the closest vector in a discrete lattice to that real vector?).
This algorithm gets really close to invalidating the security assumption of this problem, which is the basis for a lot of modern post-quantum crypto (like a lot of fully homomorphic encryption schemes), so we might expect it to fall soon.
Also: this does not affect the security of symmetric schemes like AES at all, those are still safe in a quantum world.
It's theoretically sound with a good HSM. But agreed, I'd rather rely on getting a sound software implementation of an asymmetric signature scheme than rely on protecting a symmetric key with hardware.
While security does not rely on simplicity, a simple system is much easier to reason about security. What you add is a whole stack of complexity through multiple hashes, entropy generation (on your end), and network transport (TLS).
There's no way you could convince me to use your system over a basic KDF implementation. The only people you're going to convince to use this protocol is someone who doesn't have experience in the field, which is why I'd consider your solution snake oil.
We can also detect them by a Doppler shift of the star, because the planet (if big enough) will move the star as it orbits. This works when the transit method fails, but provides fewer data on the planet itself.
That's right, symmetric encryption is fine. You're also right that protocols that rely on factoring or discrete log (more generally, any hidden subgroup problem) will be broken by quantum computers. However, this still means symmetric encryption is in trouble; namely in that we still need a post-quantum method for exchanging keys, otherwise symmetric ciphers will be virtually useless.
It's a decent introduction to P vs. NP but gets a few things wrong: factoring is technically an NP problem, but it's not (known to be) NP-complete, and packet routing is a pathfinding problem rather than a TSP, which is distinctly in P.
Also it should probably address the silly arguments that pop up that there's no bounds on the exponent for the runtime of an algorithm (O(n^100) is still in P), but this doesn't and hasn't happened in practice. And the implications for security would be huge because we would have to redefine what we mean by provable security, and then have to make some other arbitrary distinction. Is n^100 secure, but n^99 not? How does parallelization affect runtime? Things become a lot messier. So for now P vs NP is an extremely useful distinction and I have yet to see a convincing argument that it's not.
First, to clarify: what I meant by "your" was an entity like a standards community, not an individual, and by "often" I meant within a timeframe that makes bruteforcing parameters infeasible (which itself changes over time wrt the size of the parameters). Key rotation for example is just good practice.
Nothing that I said was wrong - nor does it contradict Colin's advice - and while simple systems are better, that's a tradeoff that should be made if you care about entities with lots of resources like e.g. the NSA. As history shows, bad parameters (or parameters that are feasibly bruteforced over a particular timeframe) are not an 'unlikely' weakness. Besides, being aware of potential vulnerabilities - especially those that you know pose real threats - and not addressing them is simply bad practice.
Your initial thought is why most people believed there to be little use in IO other than maybe removing software watermarks and the like. But this idea of a "punctured program" came around in which you can place the key in the program in a very clever way such that you get a security proof about hiding the key in the obfuscated program.
It turns out we can do just about anything in modern crypto using IO - it is an extremely powerful primitive - including symmetric encryption, public-key encryption, etc.
We've come a long way since the first IO result came out. Since then, we've gotten a couple more multilinear map candidates (though most are now broken), and some simpler constructions, but we're still really far from IO with a proof. This is primarily because of the underlying multilinear map that's being used. The Gentry et al result that proves IO secure in the generic multilinear model isn't that useful yet simply because there have been so many nongeneric attacks against mmap candidates, especially when they're used in IO. That is, at the moment there's no reason to believe that the generic multilinear model is even a good way to think about IO security.
What would be a really big result is finding IO that doesn't rely on multilinear maps.
One of the nice things about a lot of lattice-based crypto is that you can often just get certain homomorphic properties for free, which is why there's been a lot of recent interest in them.
This is an exceedingly good article on the current state of theoretical crypto. I would have liked to see a little more on the new things that we can do with lattices - e.g. obfuscation or homomorphic encryption - because that's really what is motivating a lot of new research.
I'm somewhat surprised that Gentry's fully homomorphic encryption wasn't mentioned. It's definitely more applied math than anything else, but if you're going to mention RSA and factoring you might as well mention the biggest crypto breakthrough in the last 5-6 years.
I don't know why we keep passing around this kind of anti-intellectual, faux-controversial drivel. Very little is required to be a programmer (whatever it means to be a programmer). No, you don't need to be an expert on algorithm analysis or complexity theory or some other CS theoretical thing to be a programmer, but it's quite obviously better to be able to reason in a certain way about certain problems (and of course asymptotic analysis isn't everything when dealing with practical applications).
The author needs to be careful in what model they are using to show asymptotic runtime. Sure, this reduces to O(log n) matrix multiplications, but matrix multiplication is not a constant time operation (and is actually between quadratic/cubic in the dimension of the matrix, assuming arithmetic operations are performed in constant time, which is also not always a great assumption).