> My understanding is that there are not very strong theoretical underpinnings to most of the machine learning techniques in use today.
I wonder how come this is the case from looking at ArXiv, it seems there are plenty of low-hanging fruit relating to the Foundations of Machine Learning.
Unfortunately I know nothing about Cryptography(Theoretical or Practical) but what benefits does QUIC bring to the table, also will it be subject to some form of formal verification ?
TL;DR: CPUs are designed to "safely" execute next instructions before having received the results of conditional checks that might have take the code path in another branch (of the "if" statement).
The safety here is achieved by not "committing" any effect of that code to "real" state (aka architectural state).
The reason I put safety in scary quotes is that it turns out that while the CPU does manage to fully undo any writes to memory and other data buffers, the actions it has taken so leave a measurable trace.
It's called a "side channel", because it's not the primary I/O channel, but a different, unintended way for data to be conveyed from the CPU to ether another device or to another program running later on the same CPU.
Cache side channel work by leveraging the measurably quicker time it takes to read memory regions related to regions recently read.
Thus when a program reads something in memory, you can later take a good guess which locations of memory it read (not every single byte, but with the granularity of a "cache line" which is e.g. 64 bytes)
The next trick is to find a spot in a program that contains code that reads some data and uses it to compute an index in another table.
If you're lucky and you find some code that for some input value computes a location in a table, you will be able to guess that value by looking at which cache line is hot.
There is a lot more to say about this, in particular about the ways you can find code that does what you want in the victim program (especially about ways you can basically reorganize code in ways never intended by the authors; read more about Return Oriented Programming)
yes, that covers the side-channel part of the picture.
the interesting aspect that spectre attacks bring to light, is that you can cause memory accesses which are explicitly forbidden because the code performs e.g. bounds checks.
speculative execution "bypasses" the checks, because that's the whole point of speculative execution: speed up the execution under the assumption that one (or the other) case is taken. If the CPU guesses that it's more likely that the bounds check will be successful, it will perform better when the input is well formed, but it let potentially malicious inputs to cause side effects detectable with side-channels leak sensitive information that the bounds check design to avoid in the first place!
As you can see, there is no easy way out here. This is a fundamental feature that makes modern CPU fast. Making sure that code can continue executing only when the results of the check is known, will affect performance of the happy path because the CPU will sit idle waiting instead of doing useful work.
> Even so, we need to instil fear into people in the West. We need to limit who they're legally allowed to sell the vulns to. Allied states: Yes. Defence interested parties: Yes. Some cybergang: Fuck no. We need to deny travel visas to the direct family members of other individuals in unaligned states that sell 0days to the worst actors.
So would that go to researchers who work on more theoretical areas(with a real world implications) things such as Static Analysis or Formal verification ?
> I think you've misunderstood what's happening here. Zerodium, the company mentioned in this article, is an exploit broker. They buy vulnerabilities from researchers, then sell them on to government intelligence agencies. The entire purpose of their business is to undermine the security of the tools we use.
It's not only Zerodium there are a lot of government contractors who buy/fund attack research especially in things like Theoretical Cryptography, Machine Learning, Computer Vision, Formal Verification.
> They incentivise researchers to publish vulnerabilities rather than selling them to spies. They're a necessary evil to keep zero-day vulnerabilities out of the hands of oppressive regimes. It's not nice, but that's just the world we live in.
I think it's quite interesting that we don't see Bug bounties for things like Theoretical Cryptography like Quantum-safe encryption, Formal Verification, and the like. But hasn't there been cases where Bug bounties have been subverted for evil or are just broken entirely.
> The Linux Foundation's Core Infrastructure Initiative has created a secure financial foundation for critical open source projects.
For critical open source projects hasn't there been an increase in Formal Verification and more Theoretical approaches to security ?
> Was there any instance of this? Are there disincentives against this? (I guess the entity offering the bounty could say, only software released before this day is available. Though malicious contributors can very certainly guess that there will be other future bug bounties too.)
I believe sometime ago there was new surrounding backdoored crypto also on the low-level side of things there was a secret rootkit in Street Fighter that allowed for an EOP
> This makes me sad. People working on open source projects get nothing. Sometimes they get some money. Sometimes they get some fame. People who don't build anything, but find a hole, they are heroes, they get prizes, they are worshiped.
I've been looking at open source communities especially in the Vulnerability research space it seems there's been a lot of favoritism towards attack oriented research from the community.
For those wanting to undergraduate research basically in REU in QIT what's your advice for them?,what do they need to take on such an endeavor?,what are researchers looking for in prospective students?, and finally would a researcher take on a student who hasn't had much in terms of coursework but has been teaching themselves ?
> One big problem with the conclusion is that intuitions from low dimensional spaces often don’t carry over to high dimensional spaces. e.g. common example is how the volume of the unit hypersphere intersected with hypercube ratio goes to zero. One funny thing I saw once was something like “the real curse of dimensionality is how different optimization in high dimensional spaces is compared to low dimensional spaces”.
How so usually in Pure Mathematics(Analytic area's) everything done in R^{1} R^{2} is usually generalized to R^{N} and much of the intuition carriers over. So how does it fail here in the context of Machine Learning ?
All the mechanics scale like you’d expect. You have bigger matrices containing more observations with more parameters per observation. Keep the dimensions aligned properly and everything works out just like it would with smaller vectors.
The discrepancies appear when you start dealing with probabilistic stuff. Suddenly everything’s conditioned by everything else, and your complexity skyrockets. Example: it’s easy to find people with about average height and weight, but the more physical characteristics you measure (increasing dimensionality) the more like you are to find something statistically unusual, eg very long fingers. Very interesting Air Force research on this [0]
WRT to optimization, higher dimensions can help avoid the local minima problem. When you have 1000s if possible directions to go, it’s unlikely that none of them will yield a better answer.
I wonder how come this is the case from looking at ArXiv, it seems there are plenty of low-hanging fruit relating to the Foundations of Machine Learning.