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

Reply via email to