Well. Does it require so much power, that I cannot run it on intel core2 quad Q9400, 2.66Ghz processor (4 cores) ?
Eero On Fri, Feb 16, 2018 at 4:40 AM, Walter Parker <walt...@gmail.com> wrote: > On Thu, Feb 15, 2018 at 6:11 PM, Jim Thompson <j...@netgate.com> wrote: > > > > > > > > On Feb 15, 2018, at 6:47 PM, Kyle Marek <pspps...@gmail.com> wrote: > > > > > > On 02/15/2018 05:33 PM, Jim Thompson wrote: > > >> Mr. Marek, > > >> > > >> I think you may be missing the point that this is about 2.5 and the > > RESTCONF interface, not any kind of VPN. > > > > > > I became aware of this after reading the follow up post. > > > > > >> Yes, there are constant time implementations of AES, they’re quite > > slow, as alluded here: > > >> https://www.netgate.com/blog/more-on-aes-ni.html < > > https://www.netgate.com/blog/more-on-aes-ni.html> > > >> > > >> Read the whole thing, please, and please remember that this was our > > attempt to explain what is coming for future pfSense, well before it > would > > occur. > > >> > > >> There is a whole rewrite that needs to occur for 2.5. All the PHP > goes > > away, and, as we did with the 2.3 -> 2.4 transition, which eliminated > > support for 32-bit Intel), and we promised to continue to release 2.3 > > images for 32-bit Intel for at least a year past the date of > 2.4.0-RELEASE, > > we are also on record for support the 2.4 series for at least a year > after > > the 2.5.0-RELEASE. > > > > > > As I understand, pfSense uses OpenSSL to implement these functions that > > > utilize AES-NI. Is slow bulk throughput the only reason why OpenSSL's > > > software implementations are not being allowed? > > > > > >> So many people want to make this about Netgate attempting to sell more > > appliances. This is not true, and anyone looking critically at the > > assertion would see the fallacy of it. I will attempt to outline why. > > >> > > >> It’s now early 2018, and, unknown to us (or anyone else in the FreeBSD > > community) before December last year, Meltdown and Spectre are here. > While > > the appliance model of pfSense is, as far as we can tell, unaffected by > > these (unless you load software from strange places), we’re committed to > > fixing them anyway. This will include support for 32-bit Intel on the > 2.3 > > series as FreeBSD (our upstream) implements and releases same. > > >> > > >> And, none too subtly, the Spectre attacks are (non-crypto) > cache-timing > > attacks. Point-in-fact, the AES cache-timing attack that I referenced > last > > May is, indeed, referenced on the first page of the Spectre paper. > > >> https://spectreattack.com/spectre.pdf > > > > > > I understand that Netgate offers support for non-Netgate hardware. > > > > True, but the “support” I’m talking about here is that we continue to > > maintain, build and test new releases of 2.3 and 2.4 for a period of > time. > > These are available to everyone, without charge. > > > > > > > >> What did anyone running 2.3 on a 32-bit Intel or AMD CPU pay Netgate > > for this continued support? > > >> > > >> Nothing. > > >> > > >> > > >> > > >> So assume that a miracle occurs, and a year from now we have a > > 2.5.0-RELEASE on 15-Feb-2019. This would mean that the 2.4 series of > > pfSense software would continue to be supported until at least > 15-Feb-2020. > > >> > > >> What did anyone running 2.4 on a 64-bit Intel or AMD CPU that doesn’t > > implement AES-NI pay Netgate for this continued support? > > >> > > >> Again, nothing. > > > > > > I'm failing to see why any additional effort is needed to support > > > non-AES-NI AES implementations considering OpenSSL is implementing it. > > > > If AES-NI is not available, OpenSSL will either use Vector Permutation > AES > > (VPAES https://www.shiftleft.org/papers/vector_aes/vector_aes.pdf) or > > Bit-sliced AES (BSAES https://cryptojedi.org/papers/aesbs-20090616.pdf), > > provided the SSSE3 instruction set extension is available. SSSE3 was > first > > introduced in 2006, so there is a fair chance that this will be available > > in most computers used. Both of these techniques avoid data- and > > key-dependent branches and memory references, and therefore are immune to > > known timing attacks. VPAES is used for CBC encrypt, ECB and "obscure" > > modes like OFB, CFB, while BSAES is used for CBC decrypt, CTR and XTS. > > > > The bit sliced (constant-time) implementation in OpenSSL could be used, > > but the GUI model with RESTCONF is very (very) different. Except for > the > > various “monitoring” widgets and graphs, a web browser running against > > today’s pfsense is all but silent until something like an “Apply” button > is > > pushed. With RESTCONF, things are much more “chatty”. > > > > This means that there is more load on the box to keep things encrypted. > > The bit sliced implementation in OpenSSL is slow, especially on older > > processors. I’ve run it on a J1900, and it’s glacial. > > > > As I explained in the blog post, we’re going to move 2.5 to the RESTCONF > > interface. We don’t have the resources to carry both the historic PHP > and > > RESTCONF interfaces forward. > > > > > > > >> Now remember that 2.5 is unlikely to occur by 15-Feb-2019, and thus > 2.4 > > will continue to be supported beyond 15-Feb-2020. Were we to get a > > 2.5.0-RELEASE by 1 May 2019, 2.4.x would be supported until 1 May 2020, > and > > this is three years after the initial announcement that 2.5 would > require a > > CPU with AES-NI (or other hardware crypto offload. I’ll note that ARM8v > > CPUs have instructions similar to AES-NI, and that the ARM appliances > > released by Netgate have crypto offload available.) > > >> > > >> So if the goal was to somehow coerce people into buying new > appliances, > > it’s not working until at least then, and even then, all that occurs if > you > > choose to remain on 2.4 is that some bugs won’t be fixed. > > >> > > >> So your “shame” Mr. Marek, while noted, is, in my view, specious. > > I’ve documented the cache-timing attacks possible against AES-GCM, and > you > > haven’t countered these. > > >> > > >> I’ve explained (on the forum and elsewhere) that the bit sliced AES > > implementation in OpenSSL is too slow, and you haven’t countered these, > > either. Warning: some implementations look fast until you realize that > > they’re only fast on large (say 2048 byte) blocks, and that they don’t > > “scale down” (a 576 byte payload takes exactly the same amount of time.) > > >> > > >> I’ll note that one can make a bit sliced AES implementation go faster > > with AVX instructions, but then one also has AES-NI, so the point is > moot. > > >> > > >> So any *shame*, Mr. Marek would be if I knowingly and willing put the > > security of the pfSense community at risk lest I be attacked. > > >> > > >> To be clear, this has not occurred. > > > > > > I apologize for my comments of shaming. I was under the impression that > > this was a meritless artificial limitation rather than any kind of > > > support burden. However, I still don't understand why the existing > > software solutions are insufficient in any way besides throughput. > > > > If they’re fast, they’re problematic from a security standpoint. > > > > On a Westmere (so one generation forward from your Xeons), AES GCM > > performs at 3.54 cycles/byte. > > Compare this with 10.68 cycles/byte got bitsliced AES GCM with table > > lookups (not secure) or > > 21.99 cycles/byte without table lookups (much more difficult to mount a > > side-channel attack) as implemented in OpenSSL. > > > > On a V4 Xeon, AES-GCM runs at 0.77 cycles/byte, and on the newest Xeon > > ‘Scalable’ cores, it runs at 0.65 cycles/byte. > > > > Since we just mentioned “really new hardware”… and yes, it’s off the > > subject of OpenSSL, but possibly of some interest, > > > > With TNSR (the DPDK re-write) on AWS we’re doing 4.59 gbps IPsec > > (AES-GCM-128) or 4.58 gbps IPsec (AES-CBC-128 + HMAC-SHA1) between a pair > > of C5.large instances (so those same Xeon ’Scalable’ cores), using a > single > > core. These instances have a maximum 5 gbps single stream ‘cap’. The > > traffic generator hosts used iperf3 to send traffic. Tests were run both > > with a single stream and with 4 streams. > > > > The traffic generator hosts (outside the tunnel) had their MTU adjusted > > down to 1500 (from the default value of 9001). Tests with iperf3 were > > invoked with a flag that set the TCP MSS to 1375 in order to ensure that > > each segment sent would not exceed 1500 bytes once the encapsulation > > overhead (ESP header, initialization vector, padding, integrity check > > value, outer IP header) is added. > > > > Raw (no IPsec) throughput using iperf3 was 4.79 gbps. The measurements > > taken by iperf3 use the amount of data sent in the TCP payload to > calculate > > throughput. The 32 byte TCP header (standard 20 byte TCP header plus 10 > > bytes for optional field containing timestamps and 2 bytes to pad > optional > > fields to a multiple of 4 bytes) and 20 byte IP header on each packet are > > not included in the calculation. If 52 bytes from each 1500 byte packet > are > > considered overhead that is not included in the measurement, the maximum > > result that iperf3 could achieve on a 5 gbps link would be approximately > > 4.83 gbps. > > > > Additional overhead from ESP includes 20 bytes for an outer IP header, 8 > > bytes for an ESP header, 2 bytes for padding length & next header type, > 16 > > (AES-CBC) or 8 (AES-GCM) bytes for an initialization vector, and 12 > > (HMAC-SHA1) or 16 (AES-GCM) bytes for an integrity check value. The total > > extra overhead is 58 bytes (AES-CBC HMAC-SHA1) or 54 bytes (AES-GCM). > Thus, > > the maximum measurement possible using iperf3 on a 5 Gbps link is 4.63 > gbps > > for AES-CBC-128 HMAC-SHA1 and 4.65 gbps for AES-GCM-128 ICV16. > > > > Net-net, it’s probably faster than that, since we’re obviously hitting > the > > Amazon-imposed bandwidth limit. Between a pair of i7-6950s (so Broadwell > > cores) we see 13.7 gbps (single-stream) AES-GCM-128 and 7.42 gbps > > AES-GCM-128 + HMAC-SHA1 (again, single-stream). Adding our CPIC QAT card > > gets us to 32.68/32.73 gbps respectively. > > > > > I cannot counter the attack possibility, but I would like to ask: is > > this unsolvable without hardware acceleration? > > > > It has a lot to do with what one might consider “acceptable” performance > > of the web gui. > > > > > > > >> I side with Mr. Parker here. How long does a project have to wait > > before demanding certain features for future revisions, assuming it gives > > adequate warning to the existing and future users of that project? I’ll > > note that you didn’t answer his question. > > > > > > I never answered the question because I did not think the answer or the > > > question was relevant. Until today, it was my understanding that AES-NI > > > was simply to improve throughput of applications utilizing AES. I had > > > previously not been presented with anything to indicate that it helps > > > with any security issues such as the timing attacks discussed here. > > > > OK, but I did point these out in the blog posts of last May. Quoting: > > > > "With AES you either design, test, and verify a bitslice software > > implementation, (giving up a lot of performance in the process), leverage > > hardware offloads, or leave the resulting system open to several known > > attacks. We have selected the “leverage hardware offloads” path. The > other > > two options are either unthinkable, or involve a lot of effort for > > diminishing returns.” > > > > I’ve listed the performance of the various implementations in OpenSSL > > above. > > > > > However, to address the question in some way, I do agree that features > > > like this should be taken advantage of as much as possible. However, > > > unlike other advances such as x86 to x86_64, AES-NI does not create any > > > new functionality that did not already exist. Until the security > > > benefits have been presented, I did not see any use case where AES-NI > > > would be necessary over the software implementation. > > > > > > I would like to point out that AES-NI is not "in everything" since 2008 > > > as previously indicated. While I understand these may not fall under > the > > > "all major x64 processors" category, Intel has launched CPUs without > > > AES-NI within the past couple of years. > > > > It’s true that not everything Intel and AMD have released in the last > > decade has AES-NI. > > > > > > > > See: > > > https://ark.intel.com/Search/FeatureFilter?productType= > > processors&AESTech=false&BornOnDate=Q4%2716 > > > > > >> And, finally, Mr. Volotinen called it exactly. We announced this in > > May last year, so that those buying hardware in the now would know about > > the future requirements. Anyone buying hardware now can make an informed > > decision as to if they want to buy or otherwise obtain a platform for > > pfSense that supports AES-NI, or not. Either will work as long as they > are > > running a 2.4.x release of pfSense, and, as above, 2.4 has a plan that > > includes support until, at least, 2020. > > > > > > This is acceptable. It just also just sucks, and I understand it must > be > > > faced. > > > > > > This is, however, beyond just replacing some networking equipment, as I > > > have to replace my primary VM host due to CPU replacements supporting > > > AES-NI not existing. Before knowing that the AES-NI requirement was to > > > address the timing attack, I felt as if I have to pay for new hardware > > > due to Netgate not "wanting" non-AES-NI AES implementations being > > > utilized. Until this, I have not exactly had software support issues > > > with even this aging hardware. > > > > Nor do you now. It’s only (at least) a year after the release of 2.5 > that > > we’ll stop supporting 2.4, and then it’s a matter of when a security > issue > > or other bug that is important enough to you switch gets addressed in 2.5 > > but not in 2.4 might occur (gosh that’s an awful sentence, Jim). > > > > > I understand that a lot of people are effectively threatening to switch > > > to OpnSense due to this, but I fear that I will *have to* if I can't > > > replace my hardware by the time support for software AES ends entirely. > > > > People should run what suits their purpose best. Perhaps someone else > > will fork pfSense and continue the 2.4 train on a different track. > That’s > > the beauty of open source software. > > > > > > > See: > > > https://ark.intel.com/Search/FeatureFilter?productType= > > processors&SocketsSupported=LGA771&AESTech=true > > > > > > I thank you for addressing this with me. I appreciate your conduct with > > > me despite my comment. > > > > Sure thing. I also appreciate your response here. > > > > Thanks, > > > > Jim > > > > > > > >> Jim > > >> > > >>> On Feb 15, 2018, at 2:11 PM, Kyle Marek <pspps...@gmail.com> wrote: > > >>> > > >>> I think you're missing the point that software support exists; > pfSense > > >>> supports software AES *now*, and this is being removed. New > technology > > >>> is cool; things not working anymore is not. > > >>> > > >>> Anyway, what are are other projects such as the TLS libraries doing > > >>> about this? Is hardware acceleration really the only solution? > > >>> > > >>> On 02/15/2018 01:39 PM, Walter Parker wrote: > > >>>> Well, both Intel and AMD starting shipping the AES-NI instructions 8 > > years > > >>>> ago... > > >>>> > > >>>> How long does a project need to wait before it can require a feature > > found > > >>>> on all major x64 processors? Waiting 8-9 years seems reasonable to > me. > > >>>> > > >>>> Given the fact that the project is only supporting 64-bit and > suggests > > >>>> using a modern processor this requirement should be a non issue for > > most > > >>>> users. > > >>>> > > >>>> The only place where the AES-NI instructions are not found is in a > > small > > >>>> number of embedded/dev boards using older Celeron processors. > > >>>> > > >>>> > > >>>> Walter > > >>>> > > >>>> On Thu, Feb 15, 2018 at 9:37 AM, Kyle Marek <pspps...@gmail.com> > > wrote: > > >>>> > > >>>>> This is silly. I shouldn't have to replace my hardware to support a > > >>>>> feature I will not use... > > >>>>> > > >>>>> I shame Netgate for such an artificial limitation... > > >>>>> > > >>>>> Thank you for the information. > > >>>>> > > >>>>> On 02/15/2018 12:20 PM, Eero Volotinen wrote: > > >>>>>> Well: > > >>>>>> > > >>>>>> https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html so we > are > > >>>>> talking > > >>>>>> about 2.5 not 3.x ? > > >>>>>> > > >>>>>> "While we’re not revealing the extent of our plans, we do want to > > give > > >>>>>> early notice that, in order to support the increased cryptographic > > loads > > >>>>>> that we see as part of pfSense verison 2.5, pfSense Community > > Edition > > >>>>>> version 2.5 will include a requirement that the CPU supports > > AES-NI. On > > >>>>>> ARM-based systems, the additional load from AES operations will be > > >>>>>> offloaded to on-die cryptographic accelerators, such as the one > > found on > > >>>>>> our SG-1000 <https://www.netgate.com/products/sg-1000.html>. ARM > > v8 CPUs > > >>>>>> include instructions like AES-NI > > >>>>>> <https://www.arm.com/files/downloads/ARMv8_Architecture.pdf> that > > can be > > >>>>>> used to increase performance of the AES algorithm on these > > platforms." > > >>>>>> > > >>>>>> > > >>>>>> Eero > > >>>>>> > > >>>>>> On Thu, Feb 15, 2018 at 7:18 PM, Edwin Pers <ep...@ansencorp.com> > > wrote: > > >>>>>> > > >>>>>>> I believe I read somewhere that the new version that requires > > aes-ni > > >>>>> will > > >>>>>>> be 3.x, and they plan to continue the 2.x line alongside it, as > 3.x > > >>>>> will be > > >>>>>>> a major rewrite > > >>>>>>> > > >>>>>>> > > >>>>>>> -Ed > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of > > Eero > > >>>>>>> Volotinen > > >>>>>>> Sent: Thursday, February 15, 2018 12:14 PM > > >>>>>>> To: Kyle Marek <pspps...@gmail.com> > > >>>>>>> Cc: pfSense Support and Discussion Mailing List < > > list@lists.pfsense.org > > >>>>>>> Subject: Re: [pfSense] Configs or hardware? > > >>>>>>> > > >>>>>>> Well. Next version of pfsense (2.5) will not install into > hardware > > that > > >>>>>>> does not support AES-NI, so buying such hardware is not wise ? > > >>>>>>> > > >>>>>>> Eero > > >>>>>>> > > >>>>>>> > > > > > > Well Said. > > Thank you for sharing the numbers. > > > Walter > > > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold > _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
