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

          Activity

            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.
            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.

            yes

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

            Ok to push

            lstartseva Lena Startseva added a comment - Ok to push

            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.