Will AES-NI support be a CPU requirement for future OPNsense releases?

[fabian]

AES-NI is a set of CPU instructions on x86 architectures. It exists to increase the performance of AES operations on those CPUs. For security, it is irrelevant if it is done in software or in hardware. The same plain text with the same key must result in the same cipher text.

[lattera]

AES-NI is a set of CPU instructions on x86 architectures. It exists to increase the performance of AES operations on those CPUs. For security, it is irrelevant if it is done in software or in hardware. The same plain text with the same key must result in the same cipher text.

Note that I'm not a cryptographer and am not currently an authoritative source to talk in-depth about cryptography. Take what I'm about to say with that in mind.

AES-NI can help resolve concerns surrounding a number of side channel attacks, thus improving the security of sensitive data. You'll also usually notice a performance increase in cryptographic operations with a good hardware crypto accelerator, which AES-NI is considered. In short, vetted hardware cryptographic accelerators provide enhanced security and performance.

AES-NI is a welcomed and well-used feature. However, for an open source project which aims to be deployable to a wide range of devices, OPNsense may decide not to force use of AES-NI. Indeed, OPNsense already supports and encourages AES-NI and other crypto accelerators, though use of them is not mandatory.

edit[0]: grammar and encouragement

[franco]

I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.

Why is what important? I don't understand either. You'll have to be more specific.


Cheers,
Franco

[coffeecup25]

I just signed up to the forums and I'm considering switching to OPNSense due in small part to the AES-NI situation with pfSense 2.5 but mainly due to the way they conduct themselves on HN and Reddit regarding the change.

I noticed also that they're not longer supporting 32-bit in 2.4 but made an exception for their own ARM SG1000 (32-bit ARM CPU) it also doesn't feature AES-NI (it has its own cryptographic hardware that implements AES in hardware) but it too will get release 2.5.

But of course if we (the community) wish to use 2.4 on 32-bit we're not allowed, nor can we use cryptographic accelerators or architectures that have their own crypto hardware which isn't AES-NI.

So I have to agree that this whole situation feels like planned obsolescence to get community members to purchase branded hardware.

And that is why I'm here really, I don't like the way things are going there and I've woken up to the realities that they're moving away from openness to make money.

Regardless though I'm happy to be here and learning about OPNSense.

Me too. I'm using a Supermicro j1900 motherboard for mine. No AES-NI. No plan to toss it out either since the home router cost nearly $400 at the time I built it. Supermicro isn't cheap but it's supposed to be ultra reliable.

Going to try to convert first on a spare laptop and use a usb lan cable for the 2nd lan outlet. After I get it to work as I like, I'll install on the Supermicro and load the config from the laptop experiment.
 
If the laptop experiment fizzles I'll do the same but on Hyper-V.

[mkolenc]

I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.

Why is what important? I don't understand either. You'll have to be more specific.


Cheers,
Franco

Hi Franco,

I asked for explanation about AESNI use for performance only. You replied in three posts talking about pfSense but did not explain why you think AESNI is only for performance. It's important because I use OPNsense for security. Please advise.

[franco]

Hi mkolenc,

I asked for explanation about AESNI use for performance only. You replied in three posts talking about pfSense but did not explain why you think AESNI is only for performance. It's important because I use OPNsense for security. Please advise.

I'm sorry for not making this clearer. Of course AES-NI is about performance and security. Between the two, right now, performance is the more prevalent reason to rely on AES-NI. Security for constant-time may be of more use in the future; we are talking about 2 year window of implementation here where attacks will be carried out with growing computation time and sophistication. Yet between now and 2 years, who knows if the security argument is still true or AES-NI will have been compromised in some way? And there is more to this...

It should be of note that AES-NI is automatic. When you have it, OpenSSL and LibreSSL use it, so you get all the benefits by direct choice, performance, security and otherwise. This was and is true for pfSense, OPNsense, FreeBSD, BSD in general, Linux and so on and so forth.

This is not a matter of leaving you less protected when AES-NI is not a hard required. You already get all the benefits of what is being implied here that will maybe hit in 2 years about something that you already have. It's your choice, right now.

Let's get to the juicy part, a paper from 2013 that is used to argue AES-NI in 2017 for maybe 2019.

http://sites.nyuad.nyu.edu/moma/pdfs/moma-project-cache-timing-attacks-on-aes.pdf

Emphasis in bold letters.

Cache-timing attacks were first introduced by Bernstein
in 2005, who showed how to complete an AES key recovery
from known-plaintext timings of a network server on another
computer. He used a Pentium III as targeted server and
conjectured that the same attack could be carried out against
software running on many other CPUs. In the last part of his
paper, he encourages future work by applying the same attack
to other CPUs and other severs. He implies that with the
difficulty of writing constant-time high speed AES software, it
would be surprising if any AES-based server were immune.

It should be of note that OpenBSD is right now building a constant time AES into their OS now which is based on the BearSSL implementation, which mimics the benefit of what AES-NI offers in terms of discussed security:

http://openbsd-archive.7691.n7.nabble.com/PATCH-01-04-Constant-time-AES-implementation-td317046.html

The BearSSL take on this is also worth a read:

https://www.bearssl.org/constanttime.html#aes

In the long run this constant-time will seep into LibreSSL (as it is maintained by OpenBSD) as well so AES-NI is either about "performance only" or the argument is bogus altogether, because software in the future will exist that satisfies the heightened security properties that AES-NI offers now, or did back in 2013 anyway.

So we have:

1. An argument based on an arbitrary choice to use RESTCONF which recommends the use of AES-GCM by proxy as discussed previously (RFC 7525), and now also
2. An argument from 2013 favouring AES-NI rejecting the state of constant-time crypto security algorithm state now or in 2019 (nobody knows).

These two can be put to together to present a narrative, but it's muss less work and discussion if we don't.


Cheers,
Franco

[gnumber9]

I too will be moving to OPNsense due to future AES requirements on pfSense. I have an i3 that has the instruction set, but I bought an asrock j1900d2y with embedded passive CPU and fanless PSU for a nice quiet router/firewall. It's awesome.

I have 3 users, to think I need hardware AES is a gross exaggeration. If need be I was going to install Debian on my old toaster oven, since that's about all I would need resource wise.

I prefer BSD for my networking needs and when I posted my concerns on a pfSense forum, the responses were rude and that hardware AES is needed. So, I said (sarcastically) under their logic why don't they go ahead and require ECC RAM and ZFS for the file system and lo and behold, I got responses supporting that and it digressed into a blowhard description of what the future of technology would be and that too would be required in 2.5, but I am sure it is not. troll prolly. UGH! There was no acknowledgment for understanding how things work, it was throwing resources where they need not be.

It used to be that if you desired an enterprise like firewall on commodity hardware, pfSense was a solid go to solution and was a "selling" point. I called out Netgate on the AES thing, but I guess they have to do what they have to do. Just don't feed me that a router needs ZFS and 3 hard drives. I mean, what in the world?

Side note first router was in 99 OS/2 old AT mobo and we screwed it to the framing in the wash room.

Thank you OPNsense for understanding the scope of things.

[openletter]

This is exactly what I came here to have answered.

My plan is now to migrate to OPNsense when pfSense obsoletes my hardware. This is about "sending them a message" so that, hopefully, others can see that when you plan obsolescence, users just migrate to some other project.

I have been using various projects since around the early 00s, and I have certain standards that, when met, I will buy swag, send donations, etc (I have a pfSense sticker on my enclosure), so I like to think I'm the kind of user projects prefer to retain.