What is the limit on the data length that can be encrypted?
 The answer to this question is a little bit more complex than a simple number: the limit on the input (plaintext) really depends on the output (ciphertext), and it depends on the key you are using and on whether you are using optional features of the encryption builtins.

You can use the following formula to predict the length of the ciphertext that will result from calling EncryptByKey based on the plaintext length, the key algorithm used and whether the optional authenticator parameter is being used or not. Note: this formula is valid only for the DES and AES key families, it is not valid for RC4, and I would recommend to not even use RC4 at all)

@CipherLen = FLOOR( (8 +@PTLen + (@UsesAuth * @HASHLEN) ) / @BLOCK) + 1 )  *  @BLOCK + 16 + @BLOCK + 4

  Where:
@CipherLen:     The ciphertext length in bytes
@PTLen:           The plaintext length in bytes
@UsesAuth:      1 if using the optional authenticator parameter, 0 otherwise
@HASHLEN:   20 bytes for SHA1 (The authenticator parameter adds a SHA1 hash to the plaintext)
@BLOCK:       The length in bytes per block. 8 for the DES family, 16 for AES

Now let’s explain every part of the formula to make it easier to understand:
FLOOR( (
8                                     Encrypted internal header
+@PTLen                      Plaintext length
+ (@UsesAuth * @HASHLEN)            If the authenticator parameter is used, the plaintext will include a hash derived from it.
 ) / @BLOCK) + 1 )  *  @BLOCK     This portion of the formula as a whole predicts the length of the ciphertext, including padding. Note: If the plaintext length fits exactly in one block, there will be an additional block of padding. This part of the formula reflects this behavior
   + 16     Key GUID (not encrypted).    This information is used during decryption to identify the key that needs to be used
   + @BLOCK                Initialization vector (IV)
   + 4                               Internal header that describes the BLOB version number

  Once we have reviewed this formula, we can discuss the limitations on the encryption builtins: The output (ciphertext) is limited to up to 8000 bytes; what does this mean? This means that the plaintext limit is a little bit below the 8000 bytes (i.e. for AES encryption, using the authenticator parameter it should be around 7920 bytes ). If you try to encrypt a larger plaintext, the builtin will fail (return null) as it won’t be able to fit all the output in the available buffer.

   For certificates, the way to calculate the maximum length of plaintext we can encrypt, as well as the ciphertext length, is easier because it is based on key modulus.
@Cipher_len  = key_modulus (regardless of the plaintext length)
@Max_Plaintext_len = key_modulus – 11

   By default, the self-signed certificates created by SQL Server 2005 have a 1024 bit modulus = 128 bytes, therefore the cipher texts are always 128 bytes and the maximum plaintext that can be encrypted is 117 bytes. The same formula applies for any certificate you may want to export into the system (the limit is 3456 bits for the private keys modulus).

  For more information on this one, I recommend you to go to https://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptencrypt.asp and look at the remarks section for CryptEncrypt.

  Should I always use this formula to calculate the size of my encrypted columns?
   I strongly recommend against considering the result of the formula as a hardcoded length for your encrypted columns. I would suggest to estimate what would be the expected maximum ciphertext length (either by creating a sample using EncryptByKey directly on your system or by using the formula) and add a little bit of extra space. My personal suggestion would be to reserve at least 1 extra block (8 bytes for DES family, 16 bytes for AES), but it would really depend on the specific scenario.

  The formula I shared here is a way to predict the length of the plaintext, but there is no guarantee that this formula will work for future algorithms or even for the existing algorithms in future versions of the product. As you have noticed, SQL Server encryption includes a few fields that are not part of the ciphertext itself, and in future versions of the product there may be a need to include new fields.

  
  But I really need to encrypt BLOBs larger than 8000 bytes! Is there anything I can do?
Using the native solution, there is nothing you can do. Your application will need to slice the input before encrypting it.
  I have created a small sample code that creates a UDF (user defined function) that is essentially a wrapper around EncryptByKey. It basically partitions the data in different pieces, encrypts them, and then pastes them together in a single BLOB that can be decrypted by its counterpart wrapper UDF for DecryptByKey. I created two different set of UDFs, one for symmetric keys and one for certificates.

  The main idea behind this demo is to split the BLOB we want to encrypt in smaller segments that we can encrypt and then concatenate their ciphertexts in such a way that we can recover the individual segments, decrypt them, and paste them again in a single LOB (the original plaintext).

Demo

/***********************************************************************
*      This posting is provided "AS IS" with no warranties,
* and confers no rights.
*
* Authors:  Raul Garcia,
*    Tanmoy Dutta,
*   Pankaj Kamat,
*   Laurentiu Cristofor
* Date:   11/07/2005
* Description: 
*
*   Create a scalar functions that allow encryption and decryption
* of large objects (> 8000 bytes).
*
*     (c) 2005 Microsoft Corporation. All rights reserved.
*
**********************************************************************/

CREATE DATABASE demo_LobEncryption
go

USE demo_LobEncryption
go

--------------------------------------------------------------------
-- Create a new Encryption function – EncryptLob.
--
-- This is a wrapper around the EncryptByKey builtin
-- In order to keep this demo simple, it doesn't support
-- all the options of that builtin
--
-- PARAMETERS
--       @key_guid:        Symmetric key GUID,
--                  equivalent to EncryptByKey’s first argument.
--                         This key needs to be already opened
--                  before calling the function
--       @lob:             The plaintext to encrypt.
--                  Limits for the datalength are defined
--                  by the varbinary(max) data type
-- RETURN VALUE
--       varbinary(max):   If the encryption succeeded,
--                  it will return the encrypted data
--     as described in NOTES
--     NULL is returned if there is any error
-- NOTES:
--       The plaintext will be split in blocks that can be
--  encrypted individually and then will be concatenated together:
--       ([2 bytes - ciphertext block length][ciphertext block])
--  per plaintext block
CREATE FUNCTION dbo.EncryptLob(
@key_guid uniqueidentifier,
@lob varbinary(max) )
returns varbinary(max)
as
BEGIN
 declare @PtLimit int
 declare @Total  int
 declare @CurPos  int
 declare @Aux  varbinary(8000)
 declare @AuxLen  int
 declare @PlaintextColumnLimit int
 declare @Cipher  varbinary(max)

 -- Limit for the PT block
 SET @PtLimit = 7800
 SET @CurPos = 1
 SET @Total = datalength( @lob )
 SET @Cipher = null

 ---- Simple validation of the input parameters

 if(
            @lob is not null
            AND encryptbykey( @key_guid, 0x00 ) is not null 
            -- Can we encrypt with the key specified by the GUID
          )
 BEGIN
  WHILE @CurPos <= @Total
  BEGIN
   -- Get a new PT block
   SELECT @Aux = substring( @Lob, @CurPos, @PtLimit )
   SET @CurPos = @CurPos + @PtLimit

   -- Encrypt the PT block
   SET @Aux = encryptbykey(@key_guid, @Aux)
   -- If any block failed to decrypt,
   -- we should just return NULL (failed)
   if( @Aux is null )
    return null

   -- Get the ciphertext length
   -- 2 bytes should be enough
   SET @AuxLen = datalength( @Aux )
   SET @Aux = convert( binary(2), @AuxLen ) + @Aux

   -- Only set the @Cipher for the first block,
   -- otherwise concatenate the existing data
   -- with the new cipher block
   if( @Cipher is null )
    SET @Cipher = @Aux
   ELSE
    SET @Cipher = @Cipher + @Aux
  END
 END

 return @Cipher
END
go
-------------------------------------------------------------------
-- Create a new Decryption function - DecryptLob.
--
-- This is a wrapper around the decryptByKey builtin.
-- It is the counterpart of the EncryptLob function.
--
-- PARAMETERS
--       @Cipher:          A ciphertext that was generated by
--     EncryptLob.
--                  The decryption key needs to be already
--                  opened before calling the function
-- RETURN VALUE
--       varbinary(max):   If the decryption succeeded, it will
--                  return the plaintext as varbinary(max)
--     NULL is returned if there is any error
--
-- NOTES:
--       The ciphertext will be split in blocks that can be
--  decrypted individually and then concatenated together:
--       ([2 bytes - ciphertext block length][ciphertext block])
--  per plaintext block
CREATE FUNCTION dbo.DecryptLob( @Cipher varbinary(max) )
returns varbinary(max)
as
BEGIN
 declare @PtLimit int
 declare @Total  int
 declare @CurPos  int
 declare @Aux  varbinary(8000)
 declare @AuxLen  int
 declare @LobPt  varbinary(max)

 SET @CurPos = 1
 SET @Total = datalength( @Cipher )
 SET @LobPt = null

 -- No op for null or empty data
 if( @Cipher is not null  
   AND @Total > 0
    )
 BEGIN
  WHILE @CurPos <= @Total
  BEGIN
   -- Read the next cipher block length
   SELECT @AuxLen = substring( @Cipher, @CurPos, 2 )
   SET @CurPos = @CurPos + 2

   -- Length field validation.
   -- Any unexpected length will result in error
   if( @AuxLen <= 0 OR @AuxLen > 8000 )
    return null

   -- Get the next cipher block
   SELECT @Aux = substring( @Cipher, @CurPos, @AuxLen )
   SET @CurPos = @CurPos + @AuxLen

   -- If there is any discrepancy, 
   -- it is either a data truncation error
   -- (cipher was truncated)
   -- or a data corruption error.
   -- We will fail the whole operation.
   if( datalength( @Aux ) <> @AuxLen )
    return null

   -- Decrypt the current cipher block
   SET @Aux = decryptbykey( @Aux )

   -- ... and make sure we could decrypt it.
   -- Again, any error here will terminate 
   -- the operation and return null
   if( @Aux is null )
    return null

   -- Either set (if first block) or concatenate
   -- to the available PT we already decrypted
   if( @LobPt is null )
    SET @LobPt = @Aux
   ELSE
    SET @LobPt = @LobPt + @Aux
  END
 END

 return @LobPt
END
go

---------------------- Test
CREATE SYMMETRIC KEY key1 WITH ALGORITHM = AES_192 ENCRYPTION BY PASSWORD = '|\/|y p@22\/\/0rD'
go

OPEN SYMMETRIC KEY key1 DECRYPTION BY PASSWORD = '|\/|y p@22\/\/0rD'
go

--------------- Quick Demo
declare @x varbinary(max)
declare @y varbinary(max)
declare @z varchar(max)
declare @i int
set @i = 0
SET @x = convert( varbinary(max), '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
while @i < 15 -- PT will be a little bit less than 2MB
BEGIN
 SET @i = @i + 1
 SET @x = @x + @x
END
SELECT @y = dbo.EncryptLob( key_guid('key1'), @x )
SELECT datalength( @y ) as 'Ciphertext length'
if( @y is not null )
BEGIN
 SELECT @z = convert( varchar(max), dbo.DecryptLob( @y ))
 
 if( @z is not null )
 BEGIN
  SELECT datalength( @x) as 'original PT len', datalength(@z) as 'decrypted PT len', substring( @z, datalength(@z) - 16, 100) as 'Last 16 chars'
  if( @z = @x )
   print 'decrypted PT == original PT'
  else
   print 'Unexpected error. PTs didn''t match'
 END
 ELSE
  print 'Failed to decrypt. Make sure the key is opened'
END
ELSE
 print 'Failed to encrypt. Make sure the key is opened'
go

--------------------------------------------------------------------
--------------------------------------------------------------------
--------------------------------------------------------------------
-- Create a new Encryption function - EncryptLobByCert.
--
-- This is a wrapper around EncryptByCert builtin
-- In order to keep this demo simple, it doesn't support
-- all the options EncryptByCert supports.
--
-- PARAMETERS
--       @cert_id:         Cert ID, equivalent to EncryptByCert
--                   first argument.
--       @lob:             The plaintext to encrypt.
--                   Limits for the datalength are defined
--                         by the varbinary(max) data type
-- RETURN VALUE
--       varbinary(max):   If the encryption succeeded,
--                    it will return a byte stream that
--                    with the encrypted data. The byte stream
--                    format is described in NOTES     
--    NULL if there is any error
-- NOTES:
--       The plaintext will be split in blocks that can be
--  encrypted individually and then concatenated together:
--  ([2 bytes - ciphertext block length][ciphertext block])
--  per plaintext block
--  Remember that asymmetric key encryption/decryption is orders
--  of magnitude more expensive than symmetric key
--  encryption/decryption.
--   We recommend avoiding the use of asymmetric key encryption for
-- large amounts of data, but these functions may be used to
-- protect data < 1000 bytes that are larger than what
-- the SQL builtins are currently supporting
-- (for example, data larger than 117 bytes)
CREATE FUNCTION dbo.EncryptLobByCert( @cert_id int, @lob varbinary(max) )
returns varbinary(max)
as
BEGIN
 declare @PtLimit int
 declare @Total  int
 declare @CurPos  int
 declare @Aux  varbinary(8000)
 declare @AuxLen  int
 declare @PlaintextColumnLimit int
 declare @Cipher  varbinary(max)

 SET @Aux = encryptbycert( @cert_id, 0x00 )
 if( @Aux is null ) -- Return null if we cannot encrypt by the specified cert
  return null

 -- Calculate the limit for the PT block
 SET @PtLimit = datalength( @Aux ) - 11

 SET @CurPos = 1
 SET @Total = datalength( @lob )
 SET @Cipher = null

 ---- Simple validation of the input parameters
 WHILE @CurPos <= @Total
 BEGIN
  -- Get a new PT block
  SELECT @Aux = substring( @Lob, @CurPos, @PtLimit )
  SET @CurPos = @CurPos + @PtLimit

  -- Encrypt the PT block
  SET @Aux = encryptbycert( @cert_id, @Aux)
  -- If any block failed to decrypt,
  -- we should just return NULL (failed)
  if( @Aux is null )
   return null

  -- Get the ciphertext length
  -- 2 bytes should be enough
  SET @AuxLen = datalength( @Aux )
  SET @Aux = convert( binary(2), @AuxLen ) + @Aux

  -- Only set the @Cipher for the first block,
  -- otherwise concatenate the existing data with
  -- the new cipher block
  if( @Cipher is null )
   SET @Cipher = @Aux
  ELSE
   SET @Cipher = @Cipher + @Aux
 END

 return @Cipher
END
go

---------------------------------------------------------------------
-- Create a new Decryption function - DecryptLobByCert.
--
-- This is a wrapper around DecryptByCert builtin.
-- It is the counterpart of EncryptLobByCert function.
--
-- PARAMETERS
--       @cert_id:         Cert ID, equivalent to EncryptByCert
--                     first argument.
--       @Cipher:          A ciphertext that was generated by
--                     EncryptLobByCert.
--       @Password:        Password for the private key.
--                     If encrypted by DBMK, you should use null
--        for this parameter.
--
-- RETURN VALUE
--       varbinary(max):   If the decryption succeeded, it will
--                     return the plaintext as varbinary(max)
--
-- NOTES
--       The plaintext will be split in blocks that can be
-- encrypted individually and then concatenated together:
-- ([2 bytes - ciphertext block length][ciphertext block])
-- per plaintext block
CREATE FUNCTION dbo.DecryptLobByCert(
@cert_id int,
@Cipher varbinary(max),
@Password nvarchar(4000) )
returns varbinary(max)
as
BEGIN
 declare @PtLimit  int
 declare @Total  int
 declare @CurPos  int
 declare @Aux  varbinary(8000)
 declare @AuxLen  int
 declare @LobPt  varbinary(max)

 SET @CurPos = 1
 SET @Total = datalength( @Cipher )
 SET @LobPt = null

 -- No op for null or empty data
 if( @Cipher is not null  
   AND @Total > 0
    )
 BEGIN
  WHILE @CurPos <= @Total
  BEGIN
   -- Read the next cipher block length
   SELECT @AuxLen = substring( @Cipher, @CurPos, 2 )
   SET @CurPos = @CurPos + 2

   -- Length field validation. Any unexpected
   -- length will result in error
   if( @AuxLen <= 0 OR @AuxLen > 8000 )
    return null

   -- Get the next cipher block
   SELECT @Aux = substring( @Cipher, @CurPos, @AuxLen )
   SET @CurPos = @CurPos + @AuxLen

   -- If there is any discrepancy,
   -- it is either a data truncation error
   -- (cipher was truncated)
   -- or a data corruption error.
   -- We will fail the whole operation.
   if( datalength( @Aux ) <> @AuxLen )
    return null

   -- Decrypt the current cipher block
   SET @Aux = decryptbycert( @cert_id, @Aux, @Password )

   -- ... and make sure we could decrypt it.
   -- Again, any error here will terminate
   -- the operation and return null
   if( @Aux is null )
    return null

   -- Either set (if first block) or concatenate
   -- to the available PT we already decrypted
   if( @LobPt is null )
    SET @LobPt = @Aux
   ELSE
    SET @LobPt = @LobPt + @Aux
  END
 END

 return @LobPt
END
go

------------ Test
CREATE CERTIFICATE certTest ENCRYPTION BY PASSWORD = 'c3R+ p@zz\/\/0Rd!' WITH SUBJECT = 'Demo - LOB encryption'
go

declare @x varbinary(max)
declare @y varbinary(max)
declare @z varchar(max)
declare @i int
set @i = 0
SET @x = convert( varbinary(max), '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
while @i < 4 -- PT will be a little bit more than 1k
BEGIN
 SET @i = @i + 1
 SET @x = @x + @x
END
SELECT @y = dbo.EncryptLobByCert( cert_id('CertTest'), @x )
SELECT datalength( @y ) as 'Ciphertext length'
--select @y as CipherTextLob
if( @y is not null )
BEGIN
 SELECT @z = convert( varchar(max), dbo.DecryptLobByCert( cert_id('CertTest'), @y, N'c3R+ p@zz\/\/0Rd!' ))
 
 if( @z is not null )
 BEGIN
  SELECT datalength( @x) as 'original PT len', datalength(@z) as 'decrypted PT len', substring( @z, datalength(@z) - 16, 100) as 'Last 16 chars'
  if( @z = @x )
   print 'decrypted PT == original PT'
  else
   print 'Unexpected error. PTs didn''t match'
 END
 ELSE
  print 'Failed to decrypt. Make sure the key is opened'
END
ELSE
 print 'Failed to encrypt. Make sure the key is opened'
go

------ Test2
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'D8|\/||< p455\/\/oRx!'
go

CREATE CERTIFICATE certTest2 WITH SUBJECT = 'Demo - LOB encryption DBMK protected'
go

declare @x varbinary(max)
declare @y varbinary(max)
declare @z varchar(max)
declare @i int
set @i = 0
SET @x = convert( varbinary(max), '1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ')
while @i < 4 -- PT will be a little more than 1k
BEGIN
 SET @i = @i + 1
 SET @x = @x + @x
END
SELECT @y = dbo.EncryptLobByCert( cert_id('CertTest2'), @x )
SELECT datalength( @y ) as 'Ciphertext length'
--select @y as CipherTextLob
if( @y is not null )
BEGIN
 -- Use null for the password parameter
 SELECT @z = convert( varchar(max), dbo.DecryptLobByCert( cert_id('CertTest2'), @y, null ))
 
 if( @z is not null )
 BEGIN
  SELECT datalength( @x) as 'original PT len', datalength(@z) as 'decrypted PT len', substring( @z, datalength(@z) - 16, 100) as 'Last 16 chars'
  if( @z = @x )
   print 'decrypted PT == original PT'
  else
   print 'Unexpected error. PTs didn''t match'
 END
 ELSE
  print 'Failed to decrypt. Make sure the key is opened'
END
ELSE
 print 'Failed to encrypt. Make sure the key is opened'
go
----------------------- CLEANUP
use master
go

DROP DATABASE demo_LobEncryption
go
----------------------- END OF DEMO -----------------------

Well, not much has changed - I am still lazy as ever, inarticulate as ever - but I have been able to post my first article https://blogs.msdn.com/yukondoit/articles/480854.aspx. It is about security considerations while securing data using SQL Server 2005.

Books Online is a good resource to know the syntax for encrypting data in various ways. To make my points clear, I will at times give references to certain DDL that you need to use. But my primary goal with this blog is to just emphasize what security guarantee you get depending on what protection mechanism you choose.

It is well known that data in SQL Server 2005 should always be protected by a symmetric key. But you need to carefully choose how to protect this symmetric key. The symmetric key can be protected by a password, a certificate, an asymmetric key or any other user created symmetric key, depending on what level of protection is desired.

 To make the right decision, end users need to answer the question - 'Whom am I trying to protect my data from?' 
    Level 2: From attackers who can get access to the database files (protecting data at rest)
    Level 1: Level 2 + From the sysadmin
    Level 0: Level 1 + From the dbo

The Ultimate Protection. Only I can see my secrets.

For end users that want the Level 0 protection, the symmetric key should only be protected by a password. This is the most secure option as the sysadmin or the dbo cannot access the symmetric key in any way and the data is truly protected. Data at rest is also protected, as even if an attacker manages to steal the files, he can only decrypt the data if he knows the password. What some may perceive as a disadvantage is that each time you need to encrypt or decrypt the data; you need to ensure that the key is open. But this is only a small price you need to pay to ensure your data is fully protected. The system view sys.open_keys will show all the open keys in a session at any given time. If the key is not open, then the following DDL statement needs to be issued to open it
  OPEN SYMMETRIC KEY <key_name> DECRYPTION BY PASSWORD = '<password>'

DBO is my friend. Let him know my secrets.

For end users that want the Level 1 protection, the requirements can be eased slightly. The symmetric key should be protected by a certificate [or an asymmetric key]. The private key of the certificate [or the asymmetric key] need to be protected by the database master key i.e. at the time of creating the certificate do not specify the ENCRYPTION BY PASSWORD option.
  CREATE CERTIFICATE c1 with subject = 'EncrCert'

If you have an existing certificate [or the asymmetric key] protected by a password and you would like to use that, you can change the protection to the database master key using the following DDL statement.
  ALTER CERTIFICATE c1 WITH PRIVATE KEY DECRYPTION BY PASSWORD = '<password>'

It may not be intuitive but not specifying the ENCRYPTION BY PASSWORD option with the ALTER CERTIFICATE statement, decrypts the private key of the certificate using the password supplied with the DECRYPTION BY PASSWORD option, and re-encrypts it using the database master key.

Now comes the important part, protecting it from sysadmin. The dbo or highly privileged database user needs to make sure that the database master key should only be protected by the password. At creation time, the database master key is encrypted by the service master key by default. The Service Master Key encryption should be dropped explicitly using the following DDL statement.
  ALTER MASTER KEY DROP ENCRYPTION BY SERVICE MASTER KEY

By doing so, the database owner does have access to your data as he can use the database master key to decrypt the private key of the certificate, which can then be used to open the symmetric key and decrypt the protected data. However, you are still protected from the sysadmin as he needs to be able to open the database master key in his session, and without the password there is no way to do it once you drop the encryption by the service master key.

I only care about my data that is stolen.

For end users that want Level 2 protection, things are a piece of cake. He needs to encrypt the data with a symmetric key that is protected by a certificate [or an asymmetric key] as in Level 1 protection. The certificate [or an asymmetric key] is protected by the database master key as demonstrated earlier.

The important difference is that the database owner should not drop the encryption of the database master key by the service master key (that he gets by default at creation time) or needs to re-add the encryption of the service master key using the following DDL statement
  ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY

The sysadmin then has access to the database master key and to any entity (certificate or asymmetric key) encrypted by the database master key. Of course, this means your data is not protected from the sysadmin or the database owner, but the data at rest is protected. If someone is able to steal the database files, and is able to attach it to his own SQL Server Instance he still cannot decrypt the encrypted data, because he does not have the password to the symmetric key or access to the keys in the hierarchy, that protect the symmetric key.

For Level 1 and Level 2 protection, it is important to remember that you need to be aware if the database master key is protected by the service master key or not. You will also need to be aware that your protection level might get dropped from Level 1 to Level 2, if the owner of your database chooses to add the protection of the service master key back to the database master key.

In conclusion, there is this inherent conflict Security seems to always have with Usability. Leveraging on the key hierarchy in SQL Server 2005 eases administrative requirements slightly due to the fact that you DONT need to explicitly open the symmetric key that you use to protect data. You can build transparent data encryption around that feature, which I will cover in a later blog. But then you need to understand your data is not secure from the sysadmins and database owners.  Encrypting symmetric keys with password can make your data super secure, but you need to manage the opening and closing of the key that protects the data.

Make the choice that suits you best, but understand your security requirements and never compromise on security for usability!