Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9069

extend AES_ENCRYPT() and AES_DECRYPT() to support IV and the algorithm

Details

    • 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

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-11476 AES_ENCRYPT/DECRYPT: Improper key sizes aren't handled correctly

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          causes

          Bug - A problem which impairs or prevents the functions of the product. MDEV-31633 Assertion `!item->null_value' failed in Type_handler::Item_send_str

          • Major - Major loss of function.
          • Closed
          is blocked by

          Task - A task that needs to be done. MDEV-10332 Server 10.2: Add support for OpenSSL 1.1

          • Major - Major loss of function.
          • Closed
          is duplicated by

          Task - A task that needs to be done. MDEV-28721 Initialization vector for AES_{EN,DE}CRYPT

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed
          is part of

          Task - A task that needs to be done. MDEV-28906 MySQL 8.0 desired compatibility

          • Major - Major loss of function.
          • Open
          relates to

          Task - A task that needs to be done. MDEV-31474 KDF() function

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-33659 Server crashed at Create_func_aes_decrypt::create_native

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          links to

          Web Link CVE-2022-21592

          Activity

            Descending order - Click to sort in ascending order
            lstartseva Lena Startseva added a comment -

            Ok to push

            lstartseva Lena Startseva added a comment - Ok to push
            serg Sergei Golubchik added a comment - - edited

            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.

            serg Sergei Golubchik added a comment - - edited 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.
            serg Sergei Golubchik added a comment - - edited

            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

            serg Sergei Golubchik added a comment - - edited 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
            philipp.grafe@pitcom.de Philipp Grafe added a comment -

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

            philipp.grafe@pitcom.de Philipp Grafe added a comment - Is there already a new time schedule or version? We are also eagerly waiting for this.
            serg Sergei Golubchik added a comment -

            yes

            serg Sergei Golubchik added a comment - yes
            juanparati Juan Lago added a comment -

            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.

            juanparati Juan Lago added a comment - 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.
            georg Georg Richter added a comment -

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

            georg Georg Richter added a comment - Current GCM implementation seems to be buggy - rfc test vectors for GCM partially fail - it will need some more investigation.

            People

              serg Sergei Golubchik
              serg Sergei Golubchik
              Votes:
              15 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.