[GHC] #8153: Implement AES intrinsics

[GHC]

#8153: Implement AES intrinsics
----------------------------+----------------------------------------------
        Reporter:  schyler  |            Owner:
            Type:  feature  |           Status:  closed
  request                   |        Milestone:
        Priority:  low      |          Version:
       Component:           |         Keywords:
  Compiler                  |     Architecture:  Unknown/Multiple
      Resolution:  wontfix  |       Difficulty:  Moderate (less than a day)
Operating System:           |       Blocked By:
  Unknown/Multiple          |  Related Tickets:
 Type of failure:           |
  None/Unknown              |
       Test Case:           |
        Blocking:           |
----------------------------+----------------------------------------------
Changes (by thoughtpolice):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I personally think this ticket is misguided and an extremely bad idea.

 There's almost no reason for GHC to provide cryptographic primitives like
 this. First off, they're ridiculously unportable, powered only on AArch64
 (which we don't support at all) and AES-NI enabled Intel machines.
 Anything else either A) doesn't get support and the compiler bails or B)
 we have to implement a fallback.

 For A), that's terrible, because it basically means the intrinsics are
 unusable for large classes of people. What's the point if most people
 can't use it? And B) is terrible too, because implementing a correct,
 constant-time version of AES is tricky and we'd have to rip someone's code
 in practice and then call out to it, yadda yadda.

 But the tricker part about B is that the AES-NI intrinsics do *not* just
 let you do AES! They are specifically designed to allow you to design your
 own key schedules or other algorithms based on AES. It is *specifically*
 designed to be this flexible! A software implementation would have to
 match these characteristics, it's not as simple as "EncryptAESBytes()" and
 "DecryptAESBytes()" in C code and calling out to that. The design would
 need to be more involved.

 But fundamentally - *why* should this be in GHC? It just seems like adding
 intrinsics for the sake of it because it sounds cool. Compilers like GHC
 are simply no place for this. I don't buy the argument we can inline
 mildly better, and I don't think GHC is going to do a better job of
 utilizing these primitives than an external library can. AES-NI in
 particular is sensitive to the performance and schedule of surrounding
 code in my experience - a small wibble can easily increase/decrease speeds
 from 20% or more, and at the levels we're talking about, that's an
 absolutely ludicrous difference - and I can guarantee GHC is almost
 certainly not going to come up with a better schedule than GCC on my hand-
 optimized AES-NI example.

 And again - AES-NI is often used in custom ways. Once you begin doing this
 and bouncing between the primops (like keygenassist and rounds of aesenc)
 in-a-not-strictly-AES-fashion, I'm almost certain GHC is not going to
 compete with GCC, which will be able to produce a much better schedule and
 code

 And finally, as a security engineer in a prior life: putting cryptography
 here is just a terrible idea from a security perspective. This is all just
 better left to a library which is isolated, small, auditable, and most
 importantly '''not tied to GHC in any way'''. This is crucial. I would
 personally be skeptical of such an approach as it ties so much complexity
 into GHC vs just using some C code. The C code is easier to audit, verify,
 and examine.

 I see no point in adding this and I personally think it's just meaningless
 bloat, and I'm strongly inclined to not accept patches for this even if
 someone were to write them. So I'm going to close this ticket. But if you
 can convince me otherwise, let's hear it.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8153#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler