[MDEV-9069] extend AES_ENCRYPT() and AES_DECRYPT() to support IV and the algorithm Created: 2015-11-02  Updated: 2023-08-04  Resolved: 2023-08-02

Status: Closed
Project: MariaDB Server
Component/s: Encryption
Fix Version/s: 11.2.1

Type: Task Priority: Critical
Reporter: Sergei Golubchik Assignee: Sergei Golubchik
Resolution: Fixed Votes: 15
Labels: Preview_11.2, beginner-friendly, compat80, upstream-fixed

Issue Links:
Blocks
blocks MDEV-11476 AES_ENCRYPT/DECRYPT: Improper key siz... Open
is blocked by MDEV-10332 Server 10.2: Add support for OpenSSL 1.1 Closed
Duplicate
is duplicated by MDEV-28721 Initialization vector for AES_{EN,DE}... Closed
PartOf
is part of MDEV-28906 MySQL 8.0 desired compatibility Open
Problem/Incident
causes MDEV-31633 Assertion `!item->null_value' failed ... Closed
Relates
relates to MDEV-31474 KDF() function Closed
Sprint: 10.3.3-1

 Description   

extend AES_ENCRYPT() and AES_DECRYPT() to support IV and the algorithm. Something like

AES_ENCRYPT(text, key, [IV [, algorithm]])

and @@block_encryption_mode variable as in 5.7

NOTE:

  • change in behavior: AES_ENCRYPT(str, key) can no longer be used in persistent virtual columns (and alike)
  • New system variable block_encryption_mode


 Comments   
Comment by Georg Richter [ 2016-12-15 ]

Current GCM implementation seems to be buggy - rfc test vectors for GCM partially fail - it will need some more investigation.

Comment by Juan Lago [ 2021-05-20 ]

Is it this feature going to be implemented some day?

IV is mostly a common practice in the industry for encryption with AES-256-CBC cipher.

It makes also hard to migrate from MySQL to MariaDB due the lack of this function.

Comment by Sergei Golubchik [ 2021-05-21 ]

yes

Comment by Philipp Grafe [ 2021-07-08 ]

Is there already a new time schedule or version? We are also eagerly waiting for this.

Comment by Sergei Golubchik [ 2022-12-12 ]

MySQL implements

AES_ENCRYPT(str, key_str [,init_vector [,kdf_name [,salt [,info | iterations]]]])

with 6 positional arguments this is, I think, way out of comfort usage zone. And it does not allow to specify the mode, it has to be specified via block_encryption_mode variable. I would rather suggest

AES_ENCRYPT(str, key [,iv] [USING mode])

2- and 3-argument syntax is compatible with MySQL. Encryption mode is specified via a keyword, so it won't cause ambiguities if we'll later want to add full MySQL compatibility syntax.
But I think it'd be more user-friendly to add a separate function, say,

KDF(key_str [, kdf_name [, salt [, info | iterations]]])

which is not part of this task

Comment by Sergei Golubchik [ 2023-06-13 ]

On the other hand, the syntax without a keyword will make it a normal function with no special rules in the parser. And the server will still be able avoid ambiguities because kdf values differ from mode values.

Comment by Lena Startseva [ 2023-07-25 ]

Ok to push

Generated at Thu Feb 08 07:31:54 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.