RFC: A256-GCM

[garrefa]

Hey guys. Ill be working in closing the RSAES-OAEP PR today. Wanted to open this request for comments in order for us to start discussing what would be the best approach to add support to A256-GCM, Ill be offline tomorrow, flying to Brazil and would be nice if I have some ideas to read during the weekend. ;)

[ghost]

Hi @garrefa, thanks for opening this issue. Hope you're having a good time in 🇧🇷. Sorry I couldn't get back to you earlier. I'll do my best and try to give some inputs on this issue over the next days. Hope that's ok for you.

[garrefa]

Thats fine. Id would like just to have an idea here of how you think this could be done so I can start working on it this week.

[ghost]

Follow up: @carol-mohemian and I will have a look at possible ways to approach this and give you some feedback by the end of the day.

[ghost]

Hi @garrefa,

just so we're on the same page, we're talking about Content Encryption with AES GCM right?

Do you already know what implementation you'll use? It looks like neither Security.framework nor CommonCrypto currently support AES GCM. However, there seem to be some hacks to get it to work with CommonCrypto.

Up until now, we've been limiting ourselves to only using official Apple implementations of crypto primitives. It would probably require some work to get third-party implementations to work so they can be used for e.g. AES GCM. To be clear here: we're not against such changes, in fact, it would be cool to enable users to inject their own implementations of AsymmetricEncrypter and SymmetricEncrypter using whichever cryptographic implementation they like.

But before we go into that, we think we should agree on whether to use a third-party implementation or somehow get CommonCrypto's AES GCM to work. What do you think?

[garrefa]

Hi @daniel-mohemian.

Yes, AES GCM for content encryption. I've seem the hack you pointed me to and I was going to try that as the main option. I considered adding 3rd party implementations but they are usually paid and closed source or using the hack. Have you seem any implementation worth considering?
I think we can later try to move the content encryption options to use a plugin pattern that would allow JOSESwift to be splitted. So You could have the base JOSESwift library with the encryptions that are officially supported on CommonCrypto and extra packages that add other encryptions, possibly allowing people to create whatever extension they want to add unofficial CommonCrypto api or even 3rd party libs to handle some encryption.
But for now if possible I would just add it with the hack.
Let me know which way to go.

[ghost]

Something we definitely do not plan to support in the main repo are closed source crypto implementations.

I agree that we should eventually move towards an API where users can supply their own Encrypters and Decrypters.

Not sure if the hack will cause any problems with AppStore review since it uses private APIs of CommonCrypto. Do you know more about that?
I'd be happy to review an example implementation using the hack, if it can be added in a clean way.

cc @carol-mohemian

[victorolinasc]

I am not a Swift/iOS/Apple developer but from the hacks link (in a comment) it seems there is now an open source library doing the hacks on a "safe" way: https://github.com/soyersoyer/SwCrypt

iOS is the lowest common denominator when we choose which algorithms to whitelist on the backend and that is why I am commenting here. This would be extremely welcome. If this is an acceptable way forward I'll talk with my team to see if they can hook this up on a PR or maybe @garrefa can go ahead with his initial intention of providing this feature.

Thanks for your work!

[ghost]

Thanks @victorolinasc for the hint! I'll definitely take a look at SwCrypt. I'll let you know if this would play nice with what we currently have.

Too bad this is not something that is natively supported.

[marfurt]

Hi everyone,

Out of curiosity, does anyone have investigated whether it is possible to use SecKeyAlgorithm like eciesEncryptionStandardVariableIVX963SHA256AESGCM or rsaEncryptionOAEPSHA256AESGCM directly?

They use a specific data format that is not really documented by Apple, but if some of those algorithms perform the same operations as JWE, there might be a way to get key encryption and content encryption using AES GCM in one shot?

[ghost]

Hello everyone,

We are using a fork of JOSESwift for our own purposes and we implemented AES Key Wrap for key management. We also did AESCBC for content, done by @ramunasjurgilas that is already merged to upstream.

Anyways, since it is symmetric encryption for keys we needed to restructure a big part of the library. We haven't submitted a pull request mainly because I wasn't sure if such refactoring would suit upstream, but it might have some merit. You can take a look at our fork here: https://github.com/mtamu/JOSESwift

Note, we used CommonCrypto functions with inspiration from SwCrypt lib.

[ghost]

@marfurt

Hi everyone,

Out of curiosity, does anyone have investigated whether it is possible to use SecKeyAlgorithm like eciesEncryptionStandardVariableIVX963SHA256AESGCM or rsaEncryptionOAEPSHA256AESGCM directly?

They use a specific data format that is not really documented by Apple, but if some of those algorithms perform the same operations as JWE, there might be a way to get key encryption and content encryption using AES GCM in one shot?

I believe (but have not checked yet) that this data format is some ASN.1 object. At least, Apple seems to use ASN.1 objects as return type of SecKeyCreateSignature (see this thread in their developer forums for more detail). We currently have an open issue (#155) which might make it necessary to dig into this format to extract data from it. I thought while we're at it we could also try to get what we need out of the SecKeyAlgorithms you mentioned (if the format is similar). If possible this would be awesome, since it would enable us to do AES-GCM using Apple's native implementation without relying on any third party dependencies (which we'd still like to avoid if possible).

Thanks a ton for the suggestion! I really like it. I hope I find some time in the next days/weeks to have a more close look at the format returned by the SecKeyAlgorithms. Happy to hear suggestions or insights you guys might have!

[ghost]

@MTamu

We haven't submitted a pull request mainly because I wasn't sure if such refactoring would suit upstream, but it might have some merit.

Sorry for the late response. I had a quick look at your fork and the restructure doesn't look too bad to me! We'd be more than happy to have a closer look at it in a pull request. If you want, feel free to just submit one anytime. 🎉

[ghost]

Closing this for inactivity. For any future implementors: The new CryptoKit seems to support AEC GCM natively on iOS.