> An AES implementation that no one uses is not a very compelling argument, except as a hypothetical.
The entire whole scenario is hypothetical!!!
Yes, there aren't a lot of AES implementations that use CPU & GPU for decryption, but if you're setting up a multicore network device a CPU parallel AES implementation isn't unreasonable.
> I consider it "infeasible" if it is a significant bottleneck on the network.
So there's a lot of vague terms and hypotheticals, as you say.
I would presume it is possible to have a network where data over even a single connection traveled so fast over a Raspberry Pi 4, where you had no access to a parallel implementation of AES, where the performance impact of routing everything through the Raspberry Pi were deemed acceptable, but the consequent slowdown in performance might be deemed "infeasible" by some, 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". Another "feasible" solution would likely be to spend roughly the equivalent of two months of what you were paying for the Internet connection on the bottleneck you've created in your network.
Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario.
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.
"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?
The entire whole scenario is hypothetical!!!
Yes, there aren't a lot of AES implementations that use CPU & GPU for decryption, but if you're setting up a multicore network device a CPU parallel AES implementation isn't unreasonable.
> I consider it "infeasible" if it is a significant bottleneck on the network.
So there's a lot of vague terms and hypotheticals, as you say.
I would presume it is possible to have a network where data over even a single connection traveled so fast over a Raspberry Pi 4, where you had no access to a parallel implementation of AES, where the performance impact of routing everything through the Raspberry Pi were deemed acceptable, but the consequent slowdown in performance might be deemed "infeasible" by some, 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". Another "feasible" solution would likely be to spend roughly the equivalent of two months of what you were paying for the Internet connection on the bottleneck you've created in your network.
Yes, it's possible to construct the necessary hypothetical, but it's not exactly a common scenario.