Skip to content

For help, click the link below to get free database assistance or contact our experts for personalized support.

Encryption: Because ‘Just Trust Me’ Isn’t a Security Policy

Welcome to the world of encryption functions, where we turn your readable data into incomprehensible gibberish - on purpose! These functions let you lock up your data so tight that even your future self will need proper documentation to get back in. Don’t worry, that’s exactly what we’re here for.

You’re about to learn how to: * Lock your data (encryption) * Unlock your data (decryption) * Prove it’s really you (signatures) * Do all this without shooting yourself in the foot

First, though, let’s talk about what happens when encryption goes wrong. Because it will. Trust me.

The Ways You’ll Break This

When it comes to encryption, there are two kinds of database administrators: those who have locked themselves out of their own data, and those who will. Here’s how it typically happens:

  1. You lose the decryption key. Congratulations! Your data is now mathematically secure against everyone, including yourself.
  2. You use the wrong key with the wrong algorithm. This is like trying to open your front door with your car key while standing on your head.
  3. You encrypt something so large that the algorithm chokes, giving you neither proper ciphertext nor your original data back.
  4. You write down the decryption process on a sticky note, which mysteriously vanishes when you actually need it.

Now that we’ve covered the inevitable disasters, let’s learn how to use these functions properly.

Version Updates: New Ways to Shoot Yourself in the Foot

Percona Server for MySQL 8.0.41 adds several exciting new features. By “exciting,” I mean “providing you with more powerful ways to either properly secure your data or utterly destroy it.” Let’s explore!

  • Three ways to pad RSA encrypt and decrypt:

    pkcs1 padding: The nostalgic option Think of pkcs1 padding as the security equivalent of a 90s-era car alarm. It adds random stuffing to your message to stop pattern analysis, making your message look different each time. It’s decent protection against casual thieves but not against determined professionals with modern tools. It’s like putting your valuables in a safe that shouts “HEY! I’M A SAFE!” when touched.

    oaep padding: The paranoid (but correct) option
    oaep padding is like hiring an elite security team for your data. It adds a mathematically robust random mask that makes cryptanalysis significantly harder. It’s the equivalent of putting your letter inside a box, wrapping that box, putting it in another box with motion sensors, then mailing it to yourself through a series of cutouts. Overkill? Maybe. But you’ll be thanking me when the NSA comes knocking.
    no padding: The “I like to live dangerously” option Using no padding is like sending your credit card details on a postcard. Your message has absolutely no additional protection. It’s simpler, yes, in the way that jumping out of a plane without a parachute simplifies skydiving. Technically it works, but it exposes you to a variety of attacks that the other padding schemes protect against. Only use this if you either know exactly what you’re doing or enjoy living on the edge.
    * Two ways to pad RSA sign and verify:
    pkcs1 padding: The basic signature pkcs1 padding for signatures is like signing your name the same way every time. It takes your message, creates a fingerprint, adds some standard framing, and locks it with your private key. It works fine until someone figures out how to copy your signature style, at which point your security is compromised. It’s simple and compatible with older systems, but not the strongest option available.
    pkcs1_pss padding: The signature with flair pkcs1_pss padding is like adding a unique flourish to your signature every single time. Even when signing the exact same document twice, the signatures will look completely different - yet both will verify correctly. This makes signature forgery dramatically harder, as there’s no consistent pattern to copy. If you’re serious about security (and if you’re reading this, you should be), this is your go-to option.
    * encryption_udf.legacy_paddding_scheme system variable - for when you need to make your modern security compatible with ancient, questionable practices

  • Character set awareness - because encrypting the wrong bytes is a special kind of pain

Percona Server for MySQL 8.0.28-20 adds tools to lock your data and control just how much of it gets locked. Because sometimes you only want to protect the good china, not every dish in the house.

Character Sets and Component Encryption UDFs: The Invisible Headache-Preventer

These functions silently handle character sets for you - one of those rare instances in computing where something actually works the way it should. Behind the scenes, it’s performing charset gymnastics that would make your head explode, but you get to blissfully ignore all of it.

  • What happens to your input behind the curtain:

    • The system automatically converts technical items like algorithms, digest names, and keys into ASCII. This prevents the classic “oops, I encrypted with UTF-8 but tried to decrypt with Latin-1” disaster that has driven many a DBA to early retirement.

    • It transforms your messages and signatures into raw binary, because computers don’t care about your human-readable formats when they’re doing serious cryptography.

  • What you get back:

    • Key files return as human-readable ASCII text. You can actually view them without your terminal having a seizure.

    • Encrypted messages and signatures come back as binary data that looks like your cat walked across the keyboard after you spilled coffee on it. This is correct and expected.

BYO Keys: For the Paranoid (Smart) Administrator

Don’t trust the random number generator on your database server? Good! That’s the correct level of paranoia for someone handling sensitive data. You can generate keys externally with OpenSSL and import them into the system.

This is like bringing your own locks to a hotel instead of using the flimsy ones they provide that probably have master keys floating around. Your OpenSSL-generated keys work seamlessly with these functions.

How You Might Break This

If you import a key in the wrong format or try to use a key type that’s incompatible with your chosen algorithm, you’ll get cryptic error messages that offer zero help. Double-check your key formats before wasting hours debugging!

Digests vs. Encryption: Confuse These and You’re Doomed

These two security tools are as different as a guard dog and a safe, yet I’ve seen countless people try to use one when they needed the other. Let’s set this straight once and for all:

  • Digests (also called hashes):

    • They generate a unique fingerprint of your data, like a content checksum on steroids.
    • They tell you if someone has messed with your data, down to a single bit change.
    • You can sign them to prove they came from you, not that guy in accounting who’s always trying to change the quarterly numbers.
    • They’re mathematically ONE-WAY. Once you hash something, there’s no going back to the original data. This isn’t a limitation - it’s the entire point.
    • Common mistake: “I hashed my customer passwords for security and now I can’t log them in!” Of course you can’t - that’s how it works!
  • Encryption:

    • It’s like putting your data in a lockbox made of mathematical titanium.
    • Without the right key, the encrypted data looks like random garbage.
    • With the right key, you can fully recover your original data, bit for bit.
    • Common mistake: “I encrypted our database with a key that only Bob knew, and Bob just quit and moved to Fiji.” Say goodbye to your data!

When to Use Which

Use digests when: * You need to verify data hasn’t changed * You want to store passwords (never store actual passwords, ever!) * You need to create a digital signature

Use encryption when: * You need to keep data secret but retrieve it later * You’re storing sensitive information that must remain recoverable * You need to securely transmit data over insecure channels

Key Length: Size Matters, But Not How You Think

How do you pick the right key size? In the infosec community, there’s a tendency to just crank everything to maximum because “more security is better,” but that’s like wearing a hazmat suit to a dinner party. Let’s get practical:

  • Longer keys are like more complex locks:
  • They’re exponentially harder to break - a 2048-bit RSA key isn’t twice as strong as a 1024-bit key, it’s VASTLY stronger
  • But they’re computationally expensive - encryption and decryption take longer, sometimes MUCH longer
  • It’s the difference between a 4-digit PIN (10,000 combinations) and a 12-digit PIN (a trillion combinations)
  • Common mistake: Choosing 16,384-bit keys for routine web traffic and then wondering why your server melted down

  • Two types of cryptographic relationships:

  • Symmetric: Same key locks and unlocks (AES, etc.)

    • Like having one key that works on both sides of your door
    • Blazingly fast compared to asymmetric encryption
    • The problem: How do you securely share that key with others?
  • Asymmetric: Different keys for locking and unlocking (RSA, DSA, etc.)

    • Like a safety deposit box where you have one key and the bank has another
    • Significantly slower (think 1000x or more) than symmetric encryption
    • But solves the key distribution problem brilliantly
    • This is what we’re focusing on in this document
  • Size limits that will bite you:

  • RSA can only encrypt messages smaller than your key size (minus padding)
  • A 2048-bit key can’t encrypt a 2048-bit message - more on this particular trap later
  • If you try to encrypt something too large, you’ll get an error that explains absolutely

Functions

Time to check out your security tools! Here’s what each one does. Don’t worry if it seems like a lot - we’ll show you how to use them.

Asymmetric encryption functions

These are your lock and key tools. But they use two different keys! One key locks your stuff, and the other key unlocks it. Weird but cool.

Function Name What It Does
asymmetric_encrypt Puts your data in a math lockbox. Only the right key can open it.
asymmetric_decrypt Opens the lockbox and gets your data back.

Asymmetric key management functions

These tools help you make and manage your special keys:

Function Name What It Does
create_asymmetric_priv_key Makes your secret key. You pick how strong you want it.
create_asymmetric_pub_key Creates a public key from your secret key. This one is OK to share.

Digital Signature functions

Think of these as your personal wax seal from the old days. They prove a message really came from you:

Function Name What It Does
asymmetric_sign Stamps your message with your secret key. Like signing your name.
asymmetric_verify Checks if a signature is real or fake. Like a signature expert at a bank.
### Diffie-Hellman functions

These special tools help two people create a shared secret. Think of it like making a secret handshake over the phone.

Encryption threshold variables

These settings let you control how strong your encryption can be. They’re like speed limits for your security system. Keys that are too strong might slow down your system. It’s like having a super-heavy padlock that takes forever to open.

Setting Name What It Does Default Range
encryption_udf.dh_bits_threshold Sets how strong Diffie-Hellman keys can be 10000 1024-10000
encryption_udf.dsa_bits_threshold Sets how strong DSA keys can be 9984 1024-9984
encryption_udf.rsa_bits_threshold Sets how strong RSA keys can be 16384 1024-16384
encryption_udf.legacy_padding Turns old-style padding on or off OFF ON/OFF
## Install component_encryption_udf

Before you can lock up your data, you need to install your security tools:

  1. Use a simple command to add the encryption tools
  2. Once you run the command, all the tools are ready right away
  3. Best part: You don’t need to run any complex setup commands!

You’ll need the INSERT permission on the mysql.component table to install this. The system just adds one row to this table to remember the tools are installed.

Here’s the command you need:

mysql> INSTALL COMPONENT 'file://component_encryption_udf';

Note

If you’re building Percona Server for MySQL from scratch, these encryption tools are included by default. If you don’t want them, use the -DWITH_ENCRYPTION_UDF=OFF option when building.

User-defined functions described

asymmetric_decrypt(algorithm, crypt_str, key_str){asymmetric_decrypt}

This tool unlocks your secret message. It’s like using the right key to open your front door.

What you get back

You get your original message back as normal, readable text.

What you need

You need these things to use this function:

  • algorithm - what kind of lock you’re opening (right now, only RSA works)

  • key_str - the key to unlock your message (in PEM format). This key must:

  • Not be damaged or corrupted
  • Match the lock - if you locked with a private key, unlock with the public key

  • crypt_str - your locked message. This usually looks like random computer gibberish.

  • padding - A setting added in version 8.0.41. Think of padding like bubble wrap around your message. Your options are:

  • no - no bubble wrap at all
  • pkcs1 - a thin layer of protection
  • oaep - thick protection all around

If you don’t pick one, the system checks another setting to decide.

asymmetric_derive(pub_key_str, priv_key_str)

This tool creates a shared secret key. It’s like magic! You and your friend each know half a secret, and somehow you both end up with the same complete secret.

You need: * pub_key_str - the other person’s public key (the part they can share with anyone) * priv_key_str - your private key (the part only you should know)

What you get: * A special secret key that both you and your friend will have * The cool part: You both get the SAME key without ever sharing your private keys

asymmetric_encrypt(algorithm, str, key_str)

This tool locks up your message. Only someone with the right key can read it.

What you get back

You get your message in secret code form. It looks like random computer gibberish.

What you need

Here’s what you need to use this function:

  • algorithm - what kind of lock to use (right now, only RSA works)

  • str - your secret message. Watch out! It can’t be too long. The maximum length depends on your key size. It’s like trying to fit a letter in an envelope - if it’s too big, it won’t fit.

  • key_str - the key that locks your message (can be either a private or public key)

  • padding - A setting added in version 8.0.41. Think of padding like packing material:

  • no - no packing at all (not safe!)
  • pkcs1 - basic packing
  • oaep - premium packing with extra protection

If you don’t pick one, the system uses another setting to decide.

asymmetric_sign: Your Digital John Hancock

This is how you sign your digital messages. It’s like signing a paper document, but with math. And unlike your handwritten signature that looks the same every time, this one changes with each use. That’s a good thing!

Ways to mess this up

  • Using the wrong key (public instead of private)
  • Signing the message instead of its digest
  • Forgetting which algorithm you used
  • Losing your private key (kiss your signature goodbye!)

What you get back

A digital signature that proves it’s really you. It looks like gibberish, but that’s normal.

What you need to make it work

  1. algorithm - Pick your signature style:
  2. ‘RSA’ - The popular choice
  3. ‘DSA’ - The alternative

  4. digest_str - A fingerprint of your message

  5. Create this with the create_digest function
  6. Never sign the raw message - that’s a rookie mistake!

  7. priv_key_str - Your private key

  8. Keep this secret! It’s like the key to your digital identity
  9. Must be in PEM format (a special way computers store keys)

  10. digest_type - How to make the fingerprint

  11. Your options depend on your OpenSSL version
  12. Think of these like different ways to stamp your signature

    OpenSSL 1.0.2 OpenSSL 1.1.0 OpenSSL 1.1.1 OpenSSL 3.0.x
    md5 md5 md5 md5
    sha1 sha1 sha1 sha1
    sha224 sha224 sha224 sha224
    sha384 sha384 sha384 sha384
    sha512 sha512 sha512 sha512
    md4 md4 md4 md4
    sha md5-sha1 md5-sha1 md5-sha1
    ripemd160 ripemd160 ripemd160 sha512-224
    whirlpool whirlpool sha512-224 sha512-256
    blake2b512 sha512-256 sha3-224
    blake2s256 whirlpool sha3-256
    sm3 sha3-384
    blake2b512 sha3-512
    blake2s256
    sha3-224
    sha3-384
    sha3-512
    shake128
    shake256
    5. padding - Extra protection for your signature (added in 8.0.41)
    * pkcs1 - Basic protection, like a thin envelope
    * pkcs1_pss - Better protection, like a tamper-evident seal
    * If you don’t pick one, the system decides based on encryption_udf.legacy_padding_scheme

asymmetric_verify: The Signature Detective

This function checks if a digital signature is legit or forged. It’s like having a signature expert at the bank who knows when someone’s faking your handwriting.

Ways people try to trick this

  • Using the wrong public key
  • Trying to verify a tampered message
  • Using a different digest type than the original
  • Messing with the padding scheme

What you get back

No complex data here - just a simple yes or no: * 1 - “Yep, that’s their signature alright!” (success) * 0 - “Nice try, forger!” (failure)

What you need to check signatures

  1. algorithm - Which signature system to check
  2. Must match what was used to create the signature
  3. Works with ‘RSA’ or ‘DSA’

  4. digest_str - The fingerprint of the message

  5. Create this with the create_digest function
  6. Must use the EXACT same method as the signer did

  7. sig_str - The signature you’re checking

  8. This comes from the asymmetric_sign function
  9. Usually looks like random computer gibberish

  10. pub_key_str - The public key of the supposed signer

  11. Must match the private key that created the signature
  12. Must be in PEM format

  13. digest_type - The fingerprint method used

  14. Check the table above for options
  15. If you use the wrong one, verification will fail

  16. padding - Must match what was used to create the signature

  17. Works with RSA signatures only
  18. If you don’t pick one, the system decides based on encryption_udf.legacy_padding_scheme

create_asymmetric_priv_key: Forging Your Secret Key

This function creates your private key - the secret part of your digital identity. It’s like making a master key that only you should possess.

Ways to mess this up

  • Making a key too small (weak security)
  • Making a key too big (sloooow performance)
  • Storing your key where others can find it
  • Forgetting to back up your key somewhere safe

Taking too long?

Some keys (especially strong ones) take a while to create. If you’re getting impatient:

KILL [QUERY|CONNECTION] <id>

This works for RSA and DSA keys. DH keys are quick, so no worries there.

What you get back

A private key in PEM format - looks like a block of garbled text with header and footer lines.

What you need to create your key

  1. algorithm - What flavor of key do you want?
  2. ‘RSA’ - The most common choice
  3. ‘DSA’ - An alternative approach
  4. ‘DH’ - For creating shared secrets

  5. key_len - How strong should your key be?

  6. RSA keys: 1,024 to 16,384 bits
  7. DSA keys: 1,024 to 9,984## create_asymmetric_pub_key: The Shareable Half of Your Key

This function extracts a public key from your private key. Think of it as creating a deposit-only ATM card - people can put money in, but they can’t take any out.

Ways people mess this up

  • Mixing up which key is which (private vs public)
  • Sharing the wrong key (oops, there goes your security!)
  • Using the public key when you need the private one

What you get back

A public key in PEM format - another block of garbled text you can freely share.

What you need to extract your public key

  1. algorithm - What kind of key are we working with?
  2. Must match the private key type: ‘RSA’, ‘DSA’, or ‘DH’
  3. Get this wrong and you’ll get errors

  4. priv_key_str - Your secret private key

  5. Must be in PEM format
  6. This is the input for creating the public key

create_dh_parameters: The Secret Recipe Maker

This function creates the special math values for Diffie-Hellman keys. It’s like creating a recipe that two people will follow to create identical secret sauces without ever sharing their individual ingredients.

Warning: Patience Required!

This can take a LONG time - much longer than making regular keys. Cancel with:

KILL [QUERY|CONNECTION] <id>

Think of it like the difference between: * Making regular keys = making a sandwich * Creating DH parameters = baking bread from scratch

What you get back

A block of special values in PEM format. You’ll use these later when creating DH keys.

What you need to create parameters

key_len - How mathematically strong should these be? * Choose between 1,024 and 10,000 bits * Default is 10,000 (strongest but slowest) * Admins can adjust the maximum with encryption_udf.dh_bits_threshold

create_digest(digest_type, str)

Creates a digest from the given string using the given digest type. The digest string can be used with asymmetric_sign and asymmetric_verify.

create_digest output

The digest of the given string as a binary string

create_digest parameters

The parameters are the following:

  • digest_type - the OpenSSL version installed on your system determines the available hash functions. The following table lists these functions:

    OpenSSL 1.0.2 OpenSSL 1.1.0 OpenSSL 1.1.1 OpenSSL 3.0.x
    md5 md5 md5 md5
    sha1 sha1 sha1 sha1
    sha224 sha224 sha224 sha224
    sha384 sha384 sha384 sha384
    sha512 sha512 sha512 sha512
    md4 md4 md4 md4
    sha md5-sha1 md5-sha1 md5-sha1
    ripemd160 ripemd160 ripemd160 sha512-224
    whirlpool whirlpool sha512-224 sha512-256
    blake2b512 sha512-256 sha3-224
    blake2s256 whirlpool sha3-256
    sm3 sha3-384
    blake2b512 sha3-512
    blake2s256 sm3
    sha3-224 blake2b512
    sha3-384 blake2s256
    sha3-512 blake2b512
    shake128 blake2s256
    shake256
  • str - String used to generate the digest string.

Encryption threshold variables

OpenSSL defines the maximum key length limits. Server administrators can limit the maximum key length using the encryption threshold variables.

The variables are automatically registered when component_encryption_udf is installed.

Variable Name
encryption_udf.dh_bits_threshold

encryption_udf.dh_bits_threshold

The variable sets the maximum limit for the create_dh_parameters user-defined function and precedes the OpenSSL maximum length value.

Option Description
command-line Yes
scope Global
data type unsigned integer
default 10000

The range for this variable is from 1024 to 10,000. The default value is 10,000.

encryption_udf.dsa_bits_threshold

The variable sets the threshold limits for the create_asymmetric_priv_key user-defined function when it is invoked with the DSA parameter and takes precedence over the OpenSSL maximum length value.

Option Description
command-line Yes
scope Global
data type unsigned integer
default 9984

The range for this variable is from 1,024 to 9,984. The default value is 9,984.

encryption_udf.legacy_paddding_scheme

The variable enables or disables the legacy padding scheme for certain encryption operations.

Option Description
command-line Yes
scope Global
data type Boolean
default OFF

This system variable is a BOOLEAN type and is set to OFF by default.

This variable controls how the functions asymmetric_encrypt(), asymmetric_decrypt(), asymmetric_sign(), and asymmetric_verify() behave when you don’t explicitly set the padding parameter.

Understanding padding schemes

Think of padding like packing a box: * oaep is like using a big box with lots of bubble wrap * no padding is like using an exact-size box with no padding * pkcs1 is like using a box with just a thin layer of protection

When encryption_udf.legacy_padding_scheme is OFF (default):

  • For locking data: Functions use oaep padding (the big box with lots of bubble wrap)
  • For signing data: Functions use pkcs1_pss padding (the fancy signature style)

When encryption_udf.legacy_padding_scheme is ON:

  • For locking data: Functions use pkcs1 padding (the box with thin protection)
  • For signing data: Functions use pkcs1 padding (the basic signature style)

You can also pick a padding style yourself in the asymmetric_encrypt() and asymmetric_decrypt() functions with RSA encryption. Just add 'no', 'pkcs1', or 'oaep' as the last parameter. If you don’t pick one, the system uses whatever encryption_udf.legacy_padding_scheme is set to.

Size limits for each padding style

Padding Box How much can fit inside
oaep Your key size minus 42 bytes (less room, but most secure)
no Must be EXACTLY your key size (like a perfect-fit box)
pkcs1 Your key size minus 11 bytes (more room than oaep)

Example: How much fits in a pkcs1 box

Let’s say you have a 1024-bit RSA key:

  1. First, convert bits to bytes:
  2. 1024 bits ÷ 8 = 128 bytes

  3. Then, subtract the padding space:

  4. 128 bytes - 11 bytes = 117 bytes

  5. Result: Your message must be 117 bytes or less

If your message is bigger than what fits, you’ll need: * A bigger key size, or * A different padding style

Padding for signatures

When you sign data with asymmetric_sign() or verify with asymmetric_verify(), you can choose a padding style too: * pkcs1 - the basic style * pkcs1_pss - the extra-secure style

If you don’t pick one, the system checks the encryption_udf.legacy_padding_scheme setting. You can only use padding with RSA algorithms.

Want to learn more?

Check out this article: Digital Signatures: Another layer of Data Protection in Percona Server for MySQL

encryption_udf.rsa_bits_threshold

This setting controls how strong RSA keys can be when you create them with the create_asymmetric_priv_key function. Think of it as setting a limit on how big of a padlock you can make.

Option What it means
command-line You can set it when starting MySQL
scope Affects the whole server
data type A number without decimals
default 16384 (strongest possible)

You can choose any number between 1,024 (good) and 16,384 (extremely strong). The default is set to the maximum of 16,384.

Examples you can try

Here are some simple examples to help you get started:

Example 1: Setting limits and working with keys

This example shows how to: * Set how strong keys can be * Create your private key (your secret key) * Create your public key (the key you can share) * Lock (encrypt) some text * Unlock (decrypt) it again

-- Set Global variable
mysql> SET GLOBAL encryption_udf.dh_bits_threshold = 4096;

-- Set Global variable
mysql> SET GLOBAL encryption_udf.rsa_bits_threshold = 4096;
-- Create a private key
mysql> SET @private_key = create_asymmetric_priv_key('RSA', 3072);

-- Create a public key
mysql> SET @public_key = create_asymmetric_pub_key('RSA', @private_key);

-- Encrypt data using the private key (you can also use the public key)
mysql> SET @ciphertext = asymmetric_encrypt('RSA', 'This text is secret', @private_key);

-- Decrypt data using the public key (you can also use the private key)
-- The decrypted value @plaintext should be identical to the original 'This text is secret'
mysql> SET @plaintext = asymmetric_decrypt('RSA', @ciphertext, @public_key);

Example 2: Creating digital signatures

This example shows how to: * Create a fingerprint (digest) of your message * Sign that fingerprint with your private key * Check if the signature is real

-- Generate a digest string
mysql> SET @digest = create_digest('SHA256', 'This is the text for digest');

-- Generate a digest signature
mysql> SET @signature = asymmetric_sign('RSA', @digest, @private_key, 'SHA256');

-- Verify the signature against the digest
-- The @verify_signature must be equal to 1
mysql> SET @verify_signature = asymmetric_verify('RSA', @digest, @signature, @public_key, 'SHA256');

Example 3: Creating a shared secret

This example shows how two people can create the same secret key without ever sharing their private keys:

  • Create the recipe (DH parameter) for making the shared secret
  • Make two sets of keys (one for each person)
  • Person 1 creates the shared secret using their private key and Person 2’s public key
  • Person 2 creates the SAME shared secret using their private key and Person 1’s public key

This is like two people who each have half of a recipe - when combined, they both end up with the same final dish!

 -- Generate a DH parameter
 mysql> SET @dh_parameter = create_dh_parameters(3072);

 -- Generate DH key pairs
 mysql> SET @private_1 = create_asymmetric_priv_key('DH', @dh_parameter);
 mysql> SET @public_1 = create_asymmetric_pub_key('DH', @private_1);
 mysql> SET @private_2 = create_asymmetric_priv_key('DH', @dh_parameter);
 mysql> SET @public_2 = create_asymmetric_pub_key('DH', @private_2);

-- Generate a symmetric key using the public_1 and private_2
-- The @symmetric_1 must be identical to @symmetric_2
mysql> SET symmetric_1 = asymmetric_derive(@public_1, @private_2);

-- Generate a symmetric key using the public_2 and private_1
-- The @symmetric_2 must be identical to @symmetric_1
mysql> SET symmetric_2 = asymmetric_derive(@public_2, @private_1);

Example 4: Different ways to create keys

Here are three different ways to create and save your keys: * Using a simple variable with SET * Using a query with SELECT INTO * Saving directly to a table with INSERT

mysql> SET @private_key1 = create_asymmetric_priv_key('RSA', 3072);
mysql> SELECT create_asymmetric_priv_key('RSA', 3072) INTO @private_key2;
mysql> INSERT INTO key_table VALUES(create_asymmetric_priv_key('RSA', 3072));

Removing the encryption toolbox

When you’re done using these tools, you can remove them from your system. Think of it like uninstalling an app when you no longer need it.

Use this simple command:

mysql> UNINSTALL COMPONENT 'file://component_encryption_udf';

This removes all the encryption functions from your MySQL server.


Last update: 2025-03-17