Change from string to tailf:aes encryption for existing record

General
1

Changed a leaf in schema from string to tailf:aes-256-cfb-128-encrypted-string and performed confd upgrade.

In 7.3.2 version, after upgrade the existing values in db still show in clear-text
But, in 8.0 version, after upgrade the existing values in db are encrypted.

Is there any change w.r.t. this handling in these versions?

2

yes, when type of the field is tailf:aes-256-cfb-128-encrypted-string, data is stored in encrypted format in DB.
from confd doc

The aes-256-cfb-128-encrypted-string works exactly like des3-cbc-encrypted-string but AES/256bits in
CFB mode is used to encrypt the string. The prefix for encrypted values is '$9$'.
more about 
des3-cbc-encrypted-string:
The des3-cbc-encrypted-string type automatically encrypts a value adhering to this type using DES in CBC
mode followed by a base64 conversion

you need to use confd_decrypt API to decode the encrypted string(which prints value in clear text format).

3

hi @unavarasala -

Thanks, but I know the functionality of aes-256-cfb-128-encrypted-string. My question was NOT on that.

The question is that

  1. There is an existing schema and config with confd running in our labs
  2. Now, we change the type of a field (named ‘profile’) in our schema from string to aes-256-cfb-128-encrypted-string and perform a confd auto upgrade with the ‘new’ schema.
  3. After upgrade (when the version is confd 7.3.2), the value of the ‘profile’ field still shows data in clear text
  4. When we try same steps from 1) to 3) with confd 8.0, then auto-upgrade converts the ‘profile’ field value from string to encrypted string.

So, wanted to check if there is a change w.r.t. this behaviour between confd7.3.2 to confd8.0. @cohult - Did you get a chance to have a look? Thanks.

4

There have been many changes since 7.3.2 (May 2020), and this is likely one of them. If you take the CHANGES files from the latest 7.8.x and 8.x releases, you can perhaps identify the change if that is important.

5

Thanks @cohult for the reply. We are able to mitigate by invoking a python script during upgrade which reads the entries from running cdb and then writes to candidate db (and confd is encrypting them)