3 ms·

> The entire whole scenario is hypothetical!!! I do not agree at all. Some people may actually want to use the technique detailed in the article. Most people

> The entire whole scenario is hypothetical!!! I do not agree at all. Some people may actually want to use the technique detailed in the article. Most people do not have a powerful, enterprise-grade router they can run software on, so they would reach for another device. A Raspberry Pi is frequently used for PiHole and similar functions, so it is logical that someone would reach for a Raspberry Pi 4 here. What part of this seems hypothetical? An AES library that might not even work (since no one actually uses it), let alone is likely difficult to integrate into the software stack described in the article is extremely hypothetical in a way that the actual project would not be. That parallel AES implementation is not some proven library with great documentation... it's a random github repo that hasn't been updated in 5 years. If the feasibility of the project depends on that, that seems like a bad place to start. > where you had no access to a parallel implementation of AES You don't. Unless you're saying the author has already integrated this into the described software stack? And proven that it works. > yet if you were to drop in a comparable device with an AES-NI capable CPU, the consequent ~4x performance improvement would allow for it to be deemed "feasible". That does not seem hypothetical. That appears to be extremely real. Of course, the speedup would likely come from multiple factors, not just AES-NI, given that you can't find a Raspberry Pi with AES-NI to have a pure apples-to-apples comparison. > Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario. I have no idea what you're talking about. This scenario is not convoluted like you're trying to make it out to be.

cbsmith 3y ago
"Hypothetical" joins a list of a lot of other words like "infeasible", "random", "real", etc. where we apparently have entirely different semantic interpretations. > An AES library that might not even work (since no one actually uses it) The library I provided was the first result I got when I searched for "parallel AES", and it's not used because there aren't a lot of scenarios where people need the extra performance extracted by splitting workloads between CPUs & GPUs. Ways to improve the parallel processing of AES was still the subject of some research a decade ago, but there's not a question as to whether it is feasible today. There's just not a lot of call for software that does it because aside from brute-force attacks, in practical scenarios the hardware is already fast enough. > You don't. Unless you're saying the author has already integrated this into the described software stack? So now the scenario you've got here is someone with requirements and means at their disposal to regularly pull down data over a single connection at gigabit speeds from the Internet, but doesn't invest in their network proxy enough to get hardware that can decrypt at performance that was available for commodity hardware over a dozen years ago, who is hacking away on a Raspberry Pi to MITM their Internet access, interpret layer-7 protocols, develop software to manipulate those protocols in ways that don't break the functionality they require but do break ad platforms, but don't have the resources to swap out their encryption library? I give up. You win.

cbsmith 3y ago

"Hypothetical" joins a list of a lot of other words like "infeasible", "random", "real", etc. where we apparently have entirely different semantic interpretations. > An AES library that might not even work (since no one actually uses it) The library I provided was the first result I got when I searched for "parallel AES", and it's not used because there aren't a lot of scenarios where people need the extra performance extracted by splitting workloads between CPUs & GPUs. Ways to improve the parallel processing of AES was still the subject of some research a decade ago, but there's not a question as to whether it is feasible today. There's just not a lot of call for software that does it because aside from brute-force attacks, in practical scenarios the hardware is already fast enough. > You don't. Unless you're saying the author has already integrated this into the described software stack? So now the scenario you've got here is someone with requirements and means at their disposal to regularly pull down data over a single connection at gigabit speeds from the Internet, but doesn't invest in their network proxy enough to get hardware that can decrypt at performance that was available for commodity hardware over a dozen years ago, who is hacking away on a Raspberry Pi to MITM their Internet access, interpret layer-7 protocols, develop software to manipulate those protocols in ways that don't break the functionality they require but do break ad platforms, but don't have the resources to swap out their encryption library? I give up. You win.