#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