SOLVED Recovery Key Pool Import Puzzle

Joined
Oct 18, 2018
Messages
969
I've been interested in writing a bit of a detailed encryption guide for some time. The idea is to walk folks through how they can play with and manipulate the keys in their system to understand how FreeNAS makes use of encryption so folks could better make an informed decision about whether to use it.

In the process of putting this together I came across some odd behavior. What follows below is a bit of demonstration to show expected behavior and then steps to show the odd behavior.

Disclaimer: If you're reading this in the hopes of using this information to recover data in a lost pool, stop. Before you follow any of these instructions on a pool with data on it post your exact plan to the forums so folks can verify you're not about to lock yourself out of your pool. These are not steps one should generally take in normal operation of FreeNAS.

Other Disclaimer: If you're following along at home and my steps don't perform as expected make sure you're on the same version. While it is possible that I've made a mistake below I tried to be very diligent about testing what I wrote as I wrote it to confirm behavior. If I you think I made a mistake though definitely point it out, it is definitely possible as the steps below are somewhat involved.

The System
  • FreeNAS 11.2-U5
  • 1 encrypted pool 1 mirrored vdev of 2 disks
Terminology
FreeNAS uses confusing terminology when it comes to encryption etc.

0.key is what I will call the key that you find in /data/geli and may be referred to as /data/geli/<original>.key. It is the same key as the one you download when you first create a pool and click Download Recovery Key. It is also the same key you download when you click the lock and select Download Encrypt Key. This is the key which is typically associated with geli's slot 0, hence the name.

1.key is what I will call the key that you download when you click the lock icon and select Add Recovery Key. This is the key typically associated with geli's slot 1, hence the name.

Setup
  1. Create an encrypted pool
  2. Add a passphrase to the pool
  3. Download the primary key via Download Encrypt Key as 0.key
  4. Create and download a recovery key for the pool via Add Recovery Key as 0.key 1.key
  5. Lock and unlock the pool using the passphrase and 1.key to verify everything is working
Now, some normal steps that work as expected
  1. Export the pool (don't destroy the data on the pool)
  2. Import the pool using the primary key (0.key) passphrase pair
  3. After successful import lock the pool
  4. Unlock the pool using the passphrase
  5. Lock and then unlock the pool using the recovery key, 1.key
The above works as expected. You can perform the import above after a restart or on a different system with the same results.

Now, for something odd
  1. Export the pool (don't destroy the data on the pool)
  2. Import the pool using the recovery key (1.key). Note that here we don't use the passphrase because this key does not require a passphrase.
  3. After successful import see that you cannot lock the pool. This is somewhat expected because the key we used to import the pool has no passphrase.
  4. Move the key found in /data/geli/<original>.key to /data/geli/<original>.key_bak. If you have more than one pool this key can be identified by trial and error or by checking the storage_volume in /data/freenas_v1.db.
  5. Upload the original primary key 0.key via whatever tool you prefer, I used scp and store it in /data/geli/<original>.key
  6. Restart the machine. As expected the pool will be locked because the key you uploaded in the previous step requires a passphrase.
  7. Attempt to unlock your pool using the passphrase, it won't work! Puzzling behavior here!
  8. Attempt to unlock your pool using the recovery key, 1.key, it works.
Why did the passphrase not work? So, I had a hypothesis to explain the above behavior. Perhaps on pool import whichever key you provide is checked against both geli's User Key 0 and User Key 1 and whichever succeeds is the slot against which FreeNAS uses to check the key found in /data/geli. If this is true, swapping out the key in /data/geli shouldn't work because FreeNAS wouldn't check the key against the correct slot. Then, on further reflection I thought this unlikely, when you use geli attach to unlock a device you don't provide the slot you just provide a key file and if that key file requires a password geli prompts you for it and handles the rest. I tested it nonetheless.
  1. Create a new encrypted pool with a passphrase and download both keys as before
  2. Export and reimport your pool using 0.key and the passphrase
  3. Copy 1.key to /data/geli/<original>.key
  4. Restart the machine and notice that your pool is automatically unlocked. FreeNAS was able to use 1.key to unlock the pool without an issue.
The above works if you don't export/import your pool or if you don't use a passphrase. So it seems FreeNAS isn't picky about which key you use so long as it is stored in the correct file in /data/geli.

What about testing that exporting/importing did not invalidate our keys somehow when we import with 1.key
  1. Create a new pool with a passphrase. Download both keys, 0.key and 1.key.
  2. Export the pool
  3. Import the pool using 1.key
  4. Move /data/geli/<original>.key to /data/geli/<orignal>.key_bak
  5. Restart the machine, your pool should start out locked.
  6. Using scp upload both 0.key and 1.key
  7. Using geli, try to unlock your disks with 1.key with geli attach -k 1.key /dev/gptid/<provider>. All of the disks should work.
  8. Lock those same disks again with geli detach /dev/gptid/<provider>.eli
  9. Try to unlock them again using 0.key exactly as before. You should be prompted for a password and it should work.
Alright, so now we know that the encryption keys didn't get messed up from the import/export.

Okay, time for my final theory. Perhaps FreeNAS tracks whether a pool should make use of a passphrase at all or not? I figured I could test this by creating a pool without a passphrase, using geli directly to add a passphrase to 0.key, restart the machine and see what happens.
  1. Create a new pool without a passphrase. Download both 0.key and 1.key
  2. Add a passphrase to 0.key using the following command on each disk in the pool geli setkey -n 0 -k /data/geli/<original>.key -p -K /data/geli/<original>.key /dev/gptid/<provider>.
  3. The above command gives geli: Provider <provider> invalid. More puzzling behavior here!
Pause for a question. What gives with being unable to change the password using geli above? I did some searching around the forums and found several answers that seemed similar that suggested things related to vfs.zfs.vol.mode but they were fairly old and the links to bug reports they filed were in the old bug system and I cannot find them in the new system. I was unable to find any provider which would work while the encrypted volume was unlocked and mounted.
  1. Move /data/geli/<original>.key to /data/geli/<original>.key_bak and restart the machine so the pool and therefore disks are locked.
  2. Change the passphrase as above with geli setkey -n 0 -k /data/geli/<original>.key -p -K /data/geli/<original>.key /dev/gptid/<provider> for all disks in the pool.
  3. ls /dev/gptid to verify that no providers are attached, ie nothing there is prepended with .eli
  4. Move the key back in place mv /data/geli/<original>.key_bak /data/geli/<original>.key
  5. Attempt to unlock with the passphrase. It succeeds!
I attempted to reproduce the above error and was unable to do so on a fresh pool using either geli setkey -n 0 -k /data/geli/<original>.key -p -K /gata/geli/<original>.key /dev/gptid/<provider. or geli setkey -n 0 -K /gata/geli/<original>.key /dev/gptid/<provider.. Both seem to succeed so I must have made a mistake the first few times through.
  • After changing the password on the providers restart the system and try to unlock using the password, it should work.
Why did the password work here but not in the import step above? Okay, so this is a bit unexpected. When I imported using 1.key then placed 0.key into /data/geli the passphrase failed but when I manually set a passphrase on the disks using geli and then tried to unlock using the passphrase it worked. So it seems that sometimes FreeNAS will function with the passphrase and sometimes it will not.

It gets a bit more unexpected; after unlocking my pool using the passphrase in the prior steps clicking the lock icon does not show an option to lock the pool. Why doesn't the lock icon appear? This suggests my hypothesis is partially correct, that FreeNAS somehow knows that this pool shouldn't have a passphrase and so does not provide the option to lock it.

I've searched around and played with variations on the above and have been unable to figure this out. I don't see anything in /data/freenas_v1.db that suggests the system is aware of when and how to use a passphrase. I found old threads suggesting that the failure to change the passphrase using geli in my first attempt may be related to vfs.zfs.vol.mode but the bug referenced does not exist and is for a very old version of FreeNAS.

Edit: Corrected a typo found by @blueether
 
Last edited:

blueether

Patron
Joined
Aug 6, 2018
Messages
259
Typo?
Setup
  1. Create an encrypted pool
  2. Add a passphrase to the pool
  3. Download the primary key via Download Encrypt Key as 0.key
  4. Create and download a recovery key for the pool via Add Recovery Key as 0.key <=== 1.key?
  5. Lock and unlock the pool using the passphrase and 1.key to verify everything is working
 

cheezystix

Dabbler
Joined
Feb 22, 2019
Messages
24
I am using the same version
Created a NEW Encrypted Pool .. but I cannot even get past Create passphrase ?
I keep getting Error Creating passphrase ..
 
Joined
Oct 18, 2018
Messages
969
I am using the same version
Created a NEW Encrypted Pool .. but I cannot even get past Create passphrase ?
I keep getting Error Creating passphrase ..
You may need to move your system dataset off of that pool. The system dataset cannot live on an encrypted pool with a passphrase. If this is just a test box move it to your boot pool and call it a day.
 
Joined
Oct 18, 2018
Messages
969
I think I have a promising lead on this. I have not yet tested it, but wanted to post my most recent findings.

After some time off and on thinking about this and searching the web I returned to my original hypothesis.

that FreeNAS somehow knows that this pool shouldn't have a passphrase and so does not provide the option to lock it.

I looked around in the source code and found in the UI code some logic around which encryption actions are available based on vol_encrypt value. This lead me to search for where that value is set which lead me to a model object definition in freenas/gui/storage/models.py in the freenas repo. This was the key as I found that the possible values are defined by VolumeEncrypt_Choices whose acceptable values are defined here.

Code:
VolumeEncrypt_Choices = (
    (0, _('Unencrypted')),
    (1, _('Encrypted, no passphrase')),
    (2, _('Encrypted, with passphrase')),
)


I figured this must exist somewhere in the database and thought that storage_volume was the likely candidate. Looking there and finding this comment for a PR in the repo really connected the dots.

So, what I think is happening is this:

When you import a pool using the recovery key each disk in the pool has a value of 1 in storage_volume.vol_encrypt. You cannot then lock this pool because the system does not expect the pool to have a passphrase and thus should not be "lockable".

Additionally, when rebooting the machine and attempting to unlock with the passphrase the system wouldn't expect the pool to make use of a passphrase and thus would ignore the passphrase component. If this is true it is odd behavior; but the theory explains what is happening. I didn't yet dig through the code to verify that this is true and I might not go that far; perhaps further testing the behavior by placing 0.key in /data/geli and setting storage_volume.vol_encrypt=2 and attempting to unlock with the passphrase will be proof enough.

Do note that I don't think it matters which geli key has the passphrase. Specifically what I mean is that I don't believe that the issue is that FreeNAS is using the wrong slot when attempting to unlock. The geli command to unlock a device makes no distinction between which slot the key you are providing is associated with; but it does distinguish between keys which require a passphrase and those which don't. To use a passphrase you would do geli attach -k /path/to/geli.key /path/to/device and to not use a passphrase you would use geli attach -k /path/to/geli.key -p /path/to/device.

I'll test this soon and report back.
 
Joined
Oct 18, 2018
Messages
969
Alright, I've solved it. I tested as follows.

  1. Create a pool and set a passphrase and a recovery key, download both keys.
  2. Export the pool
  3. Import the pool using only the recovery key
  4. Observe in var/log/debug.log that for each disk the system executes geli attach -p -k /tmp/tmp9o35uniz gptid/7084775a-f11e-11e9-86e5-00074334f630 and then geli setkey -n 0 -P -K /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key /dev/gptid/7084775a-f11e-11e9-86e5-00074334f630. This second command will be important later.
  5. Now, update the database to expect a passphrase for the pool so we can lock it. sqlite3 /data/freenas-v1.db 'update storage_volume set vol_encrypt = 2 where vol_name = "test";'
  6. We can now lock the pool. This confirms my suspicion above. Now, lock the pool.
  7. Unlock the pool uploading the recovery key. It works!
  8. Attempt to unlock the pool with the passphrase. It fails, even if you select 1.key and the passphrase! What gives?
The reason the passphrase fails is that because during pool import, for every disk, User Key 0 is set as the key used to import, in this case 1.key. This overwrites the old key which occupied that slot, which was 0.key and had the passphrase. At this point, both User Key 0 and User Key 1 are set to 1.key. Of course, this situation can be tinkered with. Also note that the key set to User Key 0 is stored in /date/geli.

  1. Code:
    $ diff 1.key /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key
    $ 
    The keys are the same!
  2. Set User Key 1 to 0.key. You can run the setkey command for every provider or you can run zpool status testPool | grep gptid | xargs -I {} echo {} | awk '{print substr($0,0,42)}' | xargs -I {} geli setkey -n 1 -K 0.key {} while the pool is unlocked. You will have to enter a passphrase 2n times where n is the number of disks. For consistency use the same passphrase as was originally used on the pool.
  3. Lock the pool and unlock it with the recovery key to prove we didn't break it. It will unlock.
  4. Lock the pool and unlock it with the passphrase, it will still not work! The reason is that when you enter a passphrase the system tries to use the key found in /data/geli which, in this case, does not match the passphrase because it is still the old 1.key
  5. Lets set that key to the correct value. cp 1.key /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key.
  6. Now, unlock the pool with the passphrase. It worked! For good measure, lock it and unlock it with the recovery key, that'll work too.
Phew, what a process!

Summary
When you import a pool, whichever key you provide, whether you include a passphrase or not, is used to unlock the pool and is then set to User Key 0. This second step is subtle but important. When you add a recovery key to a pool it is set as User Key 1. If, during pool import, you provided the recovery key (which occupied User Key 1) and the system did NOT set it as User Key 0 any time you later added a new Recovery Key (1'.key it would invalidate 1.key unexpectedly.

Anyway, happy to answer any questions. I know this thread didn't get much attention. I chalk it up to the verbosity of the posts and the fact that I'm doing something very much non-standard. It was fun nonetheless.
 
Joined
Oct 22, 2019
Messages
3,579
I am SO GLAD you brought this up an investigated it. I thought I was going crazy when I exported-imported encrypted pools.

I am strongly against the way FreeNAS handles importing encrypted pools. Key Slot 0 should remain Key Slot 0 (key only, or key+pass). Key Slot 1 should remain Key Slot 1 ("recovery key"). Nothing should change in the geli header based on which key you use to re-import the pool.

One could accidentally lose access to all their data with this shell game where the "recovery key" becomes the new "original key", where the user has already backed up the original key, and assumes it is still used with their passphrase.

I prefer the way LUKS headers are handled. Key Slot 0 is always Key Slot 0. Key Slot 1 is always Key Slot 1. Key Slot 6 is always Key Slot 6. It matters not if it is a passphrase or a key file in each different slot. If you "unlock" a LUKS device using Key Slot 4, it doesn't overwrite Key Slot 0. Nothing is changed in the LUKS header.

To add to this confusion, the error message that FreeNAS 11.2 U6 spits out looks more like software bug than a legitimate error. It dumps python errors, rather than a simple message that reads "Incorrect passphrase and/or key file provided."

I never want to dive in nitty gritty with a terminal. I am trying to use FreeNAS as an "appliance", only through the Web GUI.

Going forward, should I never test out and verify that my backed up key and "recovery" work, and only use the passphrase+key combination to avoid overwriting Key Slot 0?

On that note, Key Slot 0 and Key Slot 1 seem less confusing than talks of a key, passphrase, and recovery key.

Another thing that isn't quite clear in the documentation: If I "Add" a recovery key, even if I already have one, does this always overwrite the existing Key Slot 1, which makes my previously saved recovery key useless? I can download the original key over and over and over, and it never changes Key Slot 0. Is this true for the recovery key?
 
Joined
Oct 22, 2019
Messages
3,579
I should also add, another advantage of LUKS vs how geli is implement with encrypted pools, is that each Key Slot is either a key file or a passphrase. This means one needs only to provide a passphrase, rather than always provide a mandatory key. (E.g., if I don't have my USB stick with me, which contains key files, I can always just resort to unlocking my encrypted device with a passphrase I remember. I will always have that option, regardless of whether or not I have access to my key files.)
 
Joined
Oct 18, 2018
Messages
969
Another thing that isn't quite clear in the documentation: If I "Add" a recovery key, even if I already have one, does this always overwrite the existing Key Slot 1, which makes my previously saved recovery key useless? I can download the original key over and over and over, and it never changes Key Slot 0. Is this true for the recovery key?
Yes, when you "Add Recovery Key" it generates a new key and inserts it into Slot 1. When you "Download Encyrpt Key" it simply downloads the key in /data/geli which is the key stored in Slot 0. When you "Rekey" the pool that regenerates a key and inserts it into Slot 0. Barring someone maintaining backups of their geli metadata; when you use a new key in a given slot it invalidates the prior key.

I am strongly against the way FreeNAS handles importing encrypted pools. Key Slot 0 should remain Key Slot 0 (key only, or key+pass). Key Slot 1 should remain Key Slot 1 ("recovery key"). Nothing should change in the geli header based on which key you use to re-import the pool.
The issue here is that there is not way for FreeNAS to know which key is from Slot 0 and which is from Slot 1. I do agree that the UI could a better job of making the whole system more clear though.

I should also add, another advantage of LUKS vs how geli is implement with encrypted pools, is that each Key Slot is either a key file or a passphrase.
For what its worth; I like that geli supports keys and passphrases rather than keys OR passphrases. It gives extra protection if the keyfile is compromised. I could see an argument for supporting no key only passphrase in addition to the already supported only key or key + passphrase.
 

Volte

Dabbler
Joined
Feb 11, 2016
Messages
19
all right, I've solved it. I tested as follows.

  1. Create a pool and set a passphrase and a recovery key, download both keys.
  2. Export the pool
  3. Import the pool using only the recovery key
  4. Observe in var/log/debug.log that for each disk the system executes geli attach -p -k /tmp/tmp9o35uniz gptid/7084775a-f11e-11e9-86e5-00074334f630 and then geli setkey -n 0 -P -K /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key /dev/gptid/7084775a-f11e-11e9-86e5-00074334f630. This second command will be important later.
  5. Now, update the database to expect a passphrase for the pool so we can lock it. sqlite3 /data/freenas-v1.db 'update storage_volume set vol_encrypt = 2 where vol_name = "test";'
  6. We can now lock the pool. This confirms my suspicion above. Now, lock the pool.
  7. Unlock the pool uploading the recovery key. It works!
  8. Attempt to unlock the pool with the passphrase. It fails, even if you select 1.key and the passphrase! What gives?
The reason the passphrase fails is that because during pool import, for every disk, User Key 0 is set as the key used to import, in this case 1.key. This overwrites the old key which occupied that slot, which was 0.key and had the passphrase. At this point, both User Key 0 and User Key 1 are set to 1.key. Of course, this situation can be tinkered with. Also note that the key set to User Key 0 is stored in /date/geli.

  1. Code:
    $ diff 1.key /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key
    $ 
    The keys are the same!
  2. Set User Key 1 to 0.key. You can run the setkey command for every provider or you can run zpool status testPool | grep gptid | xargs -I {} echo {} | awk '{print substr($0,0,42)}' | xargs -I {} geli setkey -n 1 -K 0.key {} while the pool is unlocked. You will have to enter a passphrase 2n times where n is the number of disks. For consistency use the same passphrase as was originally used on the pool.
  3. Lock the pool and unlock it with the recovery key to prove we didn't break it. It will unlock.
  4. Lock the pool and unlock it with the passphrase, it will still not work! The reason is that when you enter a passphrase the system tries to use the key found in /data/geli which, in this case, does not match the passphrase because it is still the old 1.key
  5. Lets set that key to the correct value. cp 1.key /data/geli/a7b329be-a479-4a82-96a4-ba2ed7dbc281.key.
  6. Now, unlock the pool with the passphrase. It worked! For good measure, lock it and unlock it with the recovery key, that'll work too.
Phew, what a process!

Summary
When you import a pool, whichever key you provide, whether you include a passphrase or not, is used to unlock the pool and is then set to User Key 0. This second step is subtle but important. When you add a recovery key to a pool it is set as User Key 1. If, during pool import, you provided the recovery key (which occupied User Key 1) and the system did NOT set it as User Key 0 any time you later added a new Recovery Key (1'.key it would invalidate 1.key unexpectedly.

Anyway, happy to answer any questions. I know this thread didn't get much attention. I chalk it up to the verbosity of the posts and the fact that I'm doing something very much non-standard. It was fun nonetheless.

@PhiloEpisteme,

Thank you for this!! I've been struggling with this recently and had the all too familiar feeling that I may have lost my data, despite my diligence and testing of backing up my recovery keys etc.

I'm a little stuck on how to proceed. I'm not sure if you have a typo above, or if you meant it this way. I'll point out the typo, and then explain what I want to do.

You said:
2. Set User Key 1 to 0.key.

As I understand it, User Key 0 is the "master", which (if electing to) should have the passphrase, and User Key 1 is the "recovery", which doesn't have a passphrase (not optional).

Shouldn't then step 2 be "Set User Key 0", since you're adding a passphrase?

Ok, so I've unlocked my pool with a recovery key. I've rekeyed my pool, and downloaded that. Now I have recovery_1.key, and recovery_2.key, assuming recovery_1.key is worthless now. (Incidentally, I cannot lock my pool—at least through the GUI—, nor can I "set passphrase", which is an option that shows up, but fails).

So what are my next steps? How do I get back to having User Key 0 (master) with a passphrase, and User Key 1 (recovery) with no passphrase. I really don't care about keeping any of the old keys (duh), so new keys are fine, I just want passphrase protection. Why anybody would want a recovery key without a passphrase, I have no idea. I suppose maybe since a recovery key is optional, it doesn't matter. Maybe I should be having no recovery key, and backing up the master key (although every time I try to backup the master key, it just seems to give me the passphraseless recovery key...)

Thoughts?!

Very best,

~ Dale
 
Joined
Oct 18, 2018
Messages
969
As I understand it, User Key 0 is the "master", which (if electing to) should have the passphrase, and User Key 1 is the "recovery", which doesn't have a passphrase (not optional).
This isn't quite the correct terminology; I appologize if I was confusing above. The "master" key is unique for every single disk and lives on the disk in the geli metadata. Two "User Keys" exist which are used to encrypt the master key such that without either "User Key" a person cannot access the "Master Key" and thus cannot access the disk.

Now, to the point of whether I had a typo . . . let me read some . . . *reads* . . . looking over it I don't think I made a typo; but I did do something very confusing. In this post, the keys sorta go something like this.

Make the pool; add a passphrase; add a recovery key
Code:
User Key 0: 0.key
User Key 1: 1.key
Key stored in /data/geli: 0.key

Export the pool
Code:
User Key 0: 0.key
User Key 1: 1.key
Key stored in /data/geli: N\A

Import the pool using 1.key
Code:
User Key 0: 1.key
User Key 1: 1.key
Key stored in /data/geli: 1.key

Trick the system into locking the pool; attempt to unlock with 0.key, the passphrase, or both and it fails; use 1.key and it works.
Code:
User Key 0: 1.key
User Key 1: 1.key
Key stored in /data/geli: 1.key

Set User Key 1 to 0.key and set a passphrase with zpool status testPool | grep gptid | xargs -I {} echo {} | awk '{print substr($0,0,42)}' | xargs -I {} geli setkey -n 1 -K 0.key {}
Code:
User Key 0: 1.key
User Key 1: 0.key
Key stored in /data/geli: 1.key

Lock the pool and try to unlock with 0.key with the passphrase; it fails. Copy 0.key into /data/geli/<key>
Code:
User Key 0: 1.key
User Key 1: 0.key
Key stored in /data/geli: 0.key

Everything works.

Do note that after doing all of this the keys have swapped places. Also note that when unlocking a pool you don't have to specify which User Key you're using; geli will try both keys with the passphrase you provide (if provided) until one works or they all fail.

Ok, so I've unlocked my pool with a recovery key. I've rekeyed my pool, and downloaded that. Now I have recovery_1.key, and recovery_2.key, assuming recovery_1.key is worthless now. (Incidentally, I cannot lock my pool—at least through the GUI—, nor can I "set passphrase", which is an option that shows up, but fails).

So what are my next steps? How do I get back to having User Key 0 (master) with a passphrase, and User Key 1 (recovery) with no passphrase. I really don't care about keeping any of the old keys (duh), so new keys are fine, I just want passphrase protection. Why anybody would want a recovery key without a passphrase, I have no idea. I suppose maybe since a recovery key is optional, it doesn't matter. Maybe I should be having no recovery key, and backing up the master key (although every time I try to backup the master key, it just seems to give me the passphraseless recovery key...)

Thoughts?!

Very best,

~ Dale
These are great questions and I'm quite certain I can help you solve it. For the sake of continuity do you mind if we use your other thread? I asked a few questions over there to try to get things rolling.

Do note that when you click "Rekey Pool" it replaces the key stored in User Key 0; which may or may not be what you're calling the recovery key.
 
Top