Can I control which algorithm SQL Server uses to hash symmetric key passphrases

Question

I will start by describing the issue / cause before asking my question:

If you are using a symmetric key in SQL to encrypt data. This can be set up as follows:

CREATE MASTER KEY ENCRYPTION BY PASSWORD='password';
CREATE CERTIFICATE My_Certificate AUTHORIZATION [dbo] WITH SUBJECT = 'My Certificate'
CREATE SYMMETRIC KEY My_Key AUTHORIZATION [dbo] ENCRYPTION BY PASSWORD='CertificatePassword' WITH IDENTITY_VALUE = 'My Key', ALGORITHM = AES_256, KEY_SOURCE = '12345-AABB-1234-BBAA' ENCRYPTION BY CERTIFICATE My_Certificate;My_Certificate

This can then be used with the de/encryptbykey function(s) to encrypt data or vise-versa.

The issue is that data encrypted on SQL Server 2016 (or a previous version) is not accessible if moved to SQL Server 2017 (after re-applying the certificate that is).

This looks to be an issue with SQL Server 2017, See: https://support.microsoft.com/en-us/help/4053407/sql-server-2017-cannot-decrypt-data-encrypted-by-earlier-versions

And the suggested fix is to ensure you have CU2 installed and to globally enable trace-flag #4631

My question is: Is it possible (and if so how) to specify which hashing algorithm should be used.

For instance, can I tell SQL to use sha2_256 for example when encrypting my certificate?

Answer 1

For instance, can I tell SQL to use sha2_256 for example when encrypting my certificate?

Unfortunately this is currently not possible or exposed via the CREATE CERTIFICATE DDL. From the documentation you can see:

 ... SQL Server 2017 uses the SHA2 hashing algorithm to hash the passphrase.
SQL Server 2016 and earlier versions of SQL Server use the SHA1 algorithm ...

And the suggested fix is to ensure you have CU2 installed and to globally enable trace-flag #4631

That is correct, in fact I put in the request for that TF to be made available.

Perhaps it is possible to do something like: decrypting all of the data, re-creating the certificate and then re-encrypting everything. - As we are sceptical about relying on trace-flags

You could do a backup and restore from 2016 to 2017, which we tested and worked without issue (for the tests we ran) instead of migrating the symmetric key. You could also decrypt everything in 2016 as you say, load it into 2017 and create a new key in 2017 but that would be a bit over the top to not use a trace flag for was is literally less than a second of wall clock time.

Also, do you have any more information about TF4631, I have been unable to locate any official documentation from Microsoft which describes this flag / what it does / how it behaves

The KB article you linked has the most information, I did write a blog post about it before CU2 came out (note that I haven't updated it since CU2 did come out so the Azure part may be incorrect as of today). In general, though, it doesn't go into the details of what the TF does. The TF changes the use to the older hashing algorithm (2012-2016 implementation) while it is enabled. That's why all you need to do is enable it, create the key, then immediately disable it.