Revisit AES-GCM on macOS

[vcsjones]

Right now Core on macOS has quasi-support for AES-GCM. It's there, but you need a modern version of OpenSsl to use it, which isn't there by default and users need to install via homebrew, or software projects need to package it themselves.

There are two new options on the table.

1. Apple's upcoming CryptoKit has support for AES-GCM (in fact, as of writing, GCM is the only AES mode it supports). This would get support on 10.15 when it releases.
2. SymCrypt is now open source. I don't know what plans have been made if any to integrate it in to CoreFx, or what the timeline for that looks like.

@bartonjs, do you have any input or thought on this? I realize nothing is going to happen for 3.0 but I'm trying to figure out long-term plans. I was contemplating building a managed wrapper around CryptoKit and releasing it as a nuget package, however if the work would be welcome in CoreFx then perhaps my effort is better spent there.

[vcsjones]

/cc @GrabYourPitchforks too.

[bartonjs]

I'm perfectly fine with the GCM code on macOS to try CryptoKit if it's on 10.15, and continuing with the OpenSSL fallback on 10.13/10.14. (If it's kept tidy it might be a reasonable thing to backport into the release/3.x family, once it can all be written).

[vcsjones]

Ok, glad to hear! I will finish up what is on my plate already soon, and explore this next.

[vcsjones]

Some disappointing news on CryptoKit - it has Swift bindings only. There is a work around but it requires bringing the Swift language and Objective-C toolchain in.

1. We would need to write some stub functions in Swift that call in to CryptoKit
2. Expose those stub functions to Objective-C via the the @objc swift attribute.
3. Write objective-c code to consume the Swift functions and have the Objective-C functions export wrappers using the cdecl calling convention that .NET understands. The Objective-C layer would also handle creating an [UInt8] from uint8_t*.

@bartonjs I suppose bringing in Swift and Objective-C is either an unacceptable or very large task, correct?

[bartonjs]

If it doesn't require any new tools that wouldn't already be present from XCode, or doesn't play well with CMake then it's probably a no-go.

I have no idea how Swift or Objective-C builds work, so I also don't know if we're talking two extra files in the shim, or two new dylibs, or what.

But I'm definitely less pleased about the idea now that it's becoming complicated 😏.

[vcsjones]

I have no idea how Swift or Objective-C builds work, so I also don't know if we're talking two extra files in the shim, or two new dylibs, or what.

One dylib with an objective-c and swift file, I think. It shouldn't require any extra tooling beyond what Xcode already has and work in cmake, but it will require a min version of cmake of 3.6.

I'll forge ahead and get something that works (edit: hopefully). Once I get there we can evaluate it to see if it is worth continuing.

I had a few discussions with some folks and it doesn't seem like they intend to add C bindings to CryptoKit for 10.15.

[vcsjones]

This is something that I've continued to poke and was hoping the have something useful for 5.0.

I have a proof of concept that works with cryptokit but required me to by-hand compile and deploy shim dylibs in a few places.

Perhaps now that Mono is in the tree, the Mono folks have some ideas on how this can fit in the build infrastructure, some day.

@akoeplinger, have y'all given any thought to being able to call Swift functions from runtime/libraries? The gist of the issue:

• CryptoKit is new in macOS 10.15 / iOS 13.
• It only has Swift bindings.
• We can shim the Swift API with a .swift file that has @objc on it, then have a Objective-C call the swift functions via bridging header, and export those functions unmangled, and also taking primitive pointers that work well with .NET's p/invoke.
• I don't know how to do the last bullet point in a way the integrates with the existing build-native parts or with cmake. I think things would be easier with Ninja, but I haven't tried yet (and I'm not sure that matters).

[akoeplinger]

We haven't thought about that from the Mono side yet, but your plan sounds reasonable.

@chamons are you aware of any gotchas with having such an objective-c/swift shim library?

[chamons]

Off top of my head no, if you wrap it in an objc header then it should work, though it is a lot of moving parts.

@spouliot @stephen-hawley - Thoughts?

[stephen-hawley]

At first blush, the API isn’t huge so if it doesn’t wrap in an ObjC header neatly, it could get encapsulated in @objc wrappers which would be accessible.