RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2095251 - Input size for AES-GCM is not limited
Summary: Input size for AES-GCM is not limited
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gnutls
Version: 9.0
Hardware: All
OS: Linux
high
unspecified
Target Milestone: rc
: ---
Assignee: Daiki Ueno
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 2108635
TreeView+ depends on / blocked
 
Reported: 2022-06-09 11:16 UTC by Ondrej Moriš
Modified: 2023-05-25 14:30 UTC (History)
2 users (show)

Fixed In Version: gnutls-3.7.6-3.el9
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 2108635 (view as bug list)
Environment:
Last Closed: 2023-05-25 14:30:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab gnutls gnutls merge_requests 1603 0 None opened cipher: limit plaintext length supplied to AES-GCM 2022-06-28 08:37:25 UTC
Red Hat Issue Tracker CRYPTO-7494 0 None None None 2022-06-09 11:57:03 UTC
Red Hat Issue Tracker RHELPLAN-124769 0 None None None 2022-06-09 11:27:13 UTC

Description Ondrej Moriš 2022-06-09 11:16:28 UTC 
Description of problem:

GnuTLS seems not to restrict the size of input for AES-GCM encryption even though NIST SP 800-38D recommends to limit it to 2^39 - 256 bits, ie. 64 GiB (recommendation for GCM mode, 5.2.1.1 Input Data).

I don't see any limits hardcoded in the code of AES-GCM and hence I tried to test is via gnutls_aead_cipher_encryptv2() as follows:

...
uint8_t data[1024];
...
iov[0].iov_len = sizeof(data);
...
gnutls_aead_cipher_init(&ch, algo, &key);
gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
1, tag, &tag_size);
...
gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
1, tag, &tag_size);
gnutls_aead_cipher_deinit(ch);

Encryption still works after the limit of 64 GiB of encrypted data is reached. Daiki confirmed that there is a limit only on TLS level but it is higher:

 * https://datatracker.ietf.org/doc/html/rfc8446#section-5.5

Even though FIPS indicators can be used to indicate when the input data size limit is reached I think the limit recommendation actually makes sense regardless of FIPS mode (this is how it work in both OpenSSL and NSS).

Version-Release number of selected component (if applicable):

gnutls-3.7.3-9.el9

Additional info:

I can supply a simple reproducer once the logic of using gnutls_aead_cipher_encryptv2() mentioned above is confirmed.
Comment 1 Daiki Ueno 2022-06-09 12:27:31 UTC 
(In reply to Ondrej Moriš from comment #0)

> gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
> 1, tag, &tag_size);
> ...
> gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
> 1, tag, &tag_size);

If I understand correctly, the limit specified in SP800-38D is per message, so I don't think it applies to repeated calls like this,
where applications are supposed to supply unique IV to each gnutls_aead_cipher_encryptv2 call.

Therefore I think the only thing we could do is to add a limit check (i.e., the length of iov is lower than the limit, per message) in gnutls_aead_cipher_encryptv2.

> Even though FIPS indicators can be used to indicate when the input data size
> limit is reached I think the limit recommendation actually makes sense
> regardless of FIPS mode (this is how it work in both OpenSSL and NSS).

I agree.
Comment 2 Ondrej Moriš 2022-06-09 12:54:33 UTC 
(In reply to Daiki Ueno from comment #1)
> (In reply to Ondrej Moriš from comment #0)
> 
> > gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
> > 1, tag, &tag_size);
> > ...
> > gnutls_aead_cipher_encryptv2(ch, iv.data, iv.size, auth_iov, 1, iov,
> > 1, tag, &tag_size);
> 
> If I understand correctly, the limit specified in SP800-38D is per message,
> so I don't think it applies to repeated calls like this,
> where applications are supposed to supply unique IV to each
> gnutls_aead_cipher_encryptv2 call.
> 
> Therefore I think the only thing we could do is to add a limit check (i.e.,
> the length of iov is lower than the limit, per message) in
> gnutls_aead_cipher_encryptv2.

Right, I was also not sure about this approach, hence your proposal makes sense to me.
Note You need to log in before you can comment on or make changes to this bug.