RFC5084: AES_GCM

[weddige]

As far as I can see, AES_GCM is not supported by asn1crypto. Was this a conscious decision, or is this an open TODO?

[jinhua115]

这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。

[MatthiasValvekens]

asn1crypto includes various OIDs that relate to AES-GCM, though? Not sure what you mean.

Just in case it wasn't clear: asn1crypto doesn't actually implement any cryptography as such, it's a library to help encode/decode ASN.1 values that are commonly used in cryptographic applications. The cryptographic operations themselves are left to other libraries (e.g. pyca's cryptography is one that comes with AES-GCM support).

[weddige]

Sorry, I should have been more precise. I was talking about

asn1crypto/asn1crypto/algos.py

Line 792 in b763a75

class EncryptionAlgorithm(_ForceNullParameters, Sequence):

From RFC5084 there is only aes128_ccm, aes192_ccm and aes256_ccm. The _gcm versions are missing and so is an GCM equivalent of CcmParams (although this should look identical). Not sure, if anything else is missing, as I am stuck here.

Would you be interested in a pull request, in case that I decide to add the missing bits? Not sure yet, how I will continue, but this might be the easiest path for me.

[mmb-davidsmith]

@weddige - I'm also running into this right now. In addition, there aren't any tests / examples I can find in the repo on how I would then use something like aes256_gcm to build an encrypted message.

[mmb-davidsmith]

I managed to get this working by defining something like the following in my class and then inserting it for parameters when building my EncryptionAlgorithm instance.

class GcmParams(core.Sequence):
    # https://tools.ietf.org/html/rfc5084
    # aes_ICVlen: 12 | 13 | 14 | 15 | 16
    _fields = [
        ('aes_nonce', core.OctetString),
        ('aes_icvlen', core.Integer),
    ]

[MatthiasValvekens]

Re: the question about PRs: I'm not the maintainer of this library, but I suppose nobody would object to a PR adding those types :)

By the way, I use some variant of that monkeypatching trick all the time to add ASN.1 definitions that are not part of the library. It's quite useful, and usually not too bad as far as hacks go...

[weddige]

In the end, I decided to not use AES_GCM, as another application wasn't supporting it as well. So no PR from me anytime soon. But I still think it would be great to have GCM included by default.