Error: Error while decrypting the ciphertext provided to safeStorage.decryptString.

[assarbad]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Signal desktop reports:

Database startup error:

Error: Error while decrypting the ciphertext provided to safeStorage.decryptString.
    at getSQLKey ([REDACTED]\app\main.js:1268:39)
    at initializeSQL ([REDACTED]\app\main.js:1317:11)
    at App.<anonymous> ([REDACTED]\app\main.js:1538:20)

App Version: 7.22.2
OS: win32

Steps to reproduce

No idea. For me it happens every other start since a few versions ago

Possibly of interest, given the error message: this is on a system where the DPAPI is defunct (Microsoft ticket has been pending for ages, they can't seem to find the root cause). DPAPI is the lowest-level Win32 API with only the NT native API being lower-level used to store and retrieve encrypted secrets such as credentials (used by Edge, Chrome etc. as well as by Credential Manager).

Expected result

I'd expect it simply to run and perform as it did a few versions back.

Actual result

Error message with the option to delete the database and start over (again: this happens every other start of the app without exaggeration).

Screenshots

Signal version

7.22.2

Operating system

Windows 10 22H2 (up-to-date)

Version of Signal on your phone

7.15.4

Link to debug log

No response

[assarbad]

Let me clarify why this is an issue: every time I need to start over it takes time to link the device afresh. But what's worse is that I lose all message history over and over again on the desktop app.

As a side note: in the aforementioned support ticket open with Microsoft, they stated that more tailored solutions should be used rather than DPAPI.

[ayumi-signal]

@assarbad Hi there and sorry this is happening for you. This is the first report we've heard of a nonfunctional DPAPI, and it seems like it's not persisting correctly. It's not possible right now to disable the DB key encryption on Windows (although it is supported on Linux). We may consider adding a command line flag for Windows.

(Also it's interesting that Microsoft support says DPAPI shouldn't be used.)

[assarbad]

@assarbad Hi there and sorry this is happening for you. This is the first report we've heard of a nonfunctional DPAPI, and it seems like it's not persisting correctly. It's not possible right now to disable the DB key encryption on Windows (although it is supported on Linux). We may consider adding a command line flag for Windows.

Is it correct to assume that this is newly introduced functionality, given that it didn't happen a few weeks back and suddenly appeared?

Any chance you could point out the Linux-side option for that? I could have a look whether I can get it going on Windows.

(Also it's interesting that Microsoft support says DPAPI shouldn't be used.)

So was I, since generally it's a catch 22 situation to securely store data. In some way the key to unseal the credentials must exist, but on the other hand it would have to be stored outside the machine on which it gets stored.

Because DPAPI uses a secret derived from the user's password hash (or optionally a machine-wide secret) and it's managed via LSASS in an opaque manner, it's always possible to decrypt secrets. After all the key is "readily" (little effort required) available.

[ayumi-signal]

Correct-- this is a new functionality to improve on-device security. We are still improving it, so appreciate your patience.

Electron docs for Linux safeStorage: --password-store="basic"
https://www.electronjs.org/docs/latest/api/safe-storage#safestoragegetselectedstoragebackend-linux

It's not going to work for Windows though, as Electron only includes this code path for Linux builds.

[assarbad]

Hi @ayumi-signal and thanks for the response. Are the old installers that aren't affected by this issue still around and available for download somehow? It would be great if you could share a download URL.

I also wanted to mention that in my professional work I have come across this on multiple customer machines as well (this is the main reason why it hasn't been fixed on my machine, because it makes more sense for Microsoft to fix it on their end¹). This bit us because we use DPAPI to store the credentials for some services encrypted. Chrome-based browsers and the Teams desktop app behave the same (using DPAPI to store credentials) and are amnesic on my system w.r.t. credentials. The worst case scenario here is that the user needs to log in time and time again. With Signal the desktop app has become unusable to me for the time being.

---

¹The underlying issue why DPAPI is defunct is as follows:

If the per-user DPAPI is used, %APPDATA%\Microsoft\Protect\%USERSID% (%USERSID% denoting the SID of the user) is used to store the chain of keys that have been used to encrypt anything with DPAPI ever. The key would generally only be created the first time a user logs on and then again when the password gets changed every now and then. On systems where DPAPI is defunct, the chain of keys keeps growing because something keeps triggering the key re-creation logic. This seems to be the consequence of one or several previous DPAPI calls failing to successfully decrypt stored secrets. I have sent traces and event logs as well as TTD traces to Microsoft in the scope of the ticket with them (at work, opened in Oct. 2022!), but so far nothing came off of it other than the suggestion to use something other than DPAPI. When I lock and unlock my system it appears to increase the likelihood of the above mentioned logic getting triggered. But I have not been able to pinpoint the cause and moreover my journey in trying to track this down has taken me down to kernel mode and up again, because the actual primitives used by DPAPI (and transiently the LSASS) are implemented there. I suspect some sort of race condition, but am not able to prove it with the level of introspection I have into Windows as a mere user.

[scottnonnenberg-signal]

@assarbad You could potential go find old Signal Desktop installers, but they will soon expire. Have you tried reinstalled windows from scratch on your machine? Or perhaps it's a hardware issue? Is there anything interesting the computer where windows is installed? Perhaps there's an underlying incompatibility?

[bozho]

Hi,

I've hit the same issue, but for a different use case. I mostly use my Windows desktop, but I also have a Windows laptop, which I use when I'm away (and that can be weeks sometimes).

Losing history on the desktop application is supremely annoying for me, since I mostly use my computers to chat, I rarely use the phone. I sync my desktop and my laptop (docs, project, select application settings), so I have set up my %APPDATA%\Roaming\Signal folder to be synced as well.

This used to work fine up until recently and when I synced my laptop a few days ago after coming back from a multi-week trip, I was greeted with this error on my desktop. Now I know why :-) My laptop and my desktop have different DPAPI keys.

I understand the desire to increase on-device security, but DPAPI is hardly the way, IMHO. If a user is logged in, the data is transparently decrypted anyway. If a user is worried about their computer getting stolen, they should be using full disk encryption anyway and any off-site backups of data should be client-side encrypted.

The only attack vector I can see where something like this might help would be a malware with just enough access to steal the encrypted data, but now enough access to be able to fetch DPAPI decryption key(s).

If you want to keep this approach, would it perhaps be possible to use Signal PIN as the key (or use it to derive a stable key) and use DPAPI to encrypt the PIN? That way, if DPAPI key changes, Signal could prompt the user for the PIN, derive the same key to decrypt the data and re-encrypt the PIN using DPAPI. If you know the PIN, you don't lose your history.

[assarbad]

You could potential go find old Signal Desktop installers, but they will soon expire.

Alright, so no real option either. Thanks.

Have you tried reinstalled windows from scratch on your machine?

Nope, and I won't (because of the open ticket among other things). Technically I probably need to clean out said directory once for my user or start over with the profile. Certainly this is no reason to reinstall Windows.

Or perhaps it's a hardware issue?

I've seen this on a variety of customer machines, as mentioned. I've also seen it on VMs I've used. So probably nothing hardware related per-se.

Is there anything interesting the computer where windows is installed? Perhaps there's an underlying incompatibility?

It can't run Windows 11 (not supported anyway), if that's what you mean. But DPAPI doesn't require a TPM or a particular version of one.

If I had more leads, I'd provide them. I have really dug deep on this one both alone and together with Microsoft's engineers and came up empty-handed. Tavis Ormandy discovered a defect that surfaces in a similar fashion and was related to S4U-type scheduled tasks. But I don't have those on my machine or the affected VMs that I can freely access. On some of the customer machines I was able to check and only one had S4U in use, IIRC. According to MS the S4U-related issue has been resolved, though. I contacted Tavis some time ago (probably ~2 years ago) and he wished me luck and voiced that he suspects a similar cause but that with all the RPC (endpoint in LSASS, IIRC, with some calls into a particular kernel driver for actual CNG stuff) calls it's very hard to debug anything.

If you read up on these threads or scour the web for NTE_BAD_KEY_STATE, you can find plenty of circumstantial evidence that DPAPI is an okay-ish choice for storing credentials that a user can then re-enter, but since we can't re-enter credentials that are created by the software under the hood, there's no way Signal desktop is ever going to work for us again without the ability to disable this — probably well-intended— feature.

References:

• https://www.bleepingcomputer.com/news/microsoft/microsoft-working-on-fix-for-windows-apps-forgetting-passwords/
  • related defect report: https://issues.chromium.org/issues/40125887#comment91
• https://borncity.com/win/2020/11/09/windows-10-2004-20h2-und-der-kaputte-credentials-manager-ursache-und-workaround/
• https://borncity.com/win/2020/11/10/windows-10-2004-20h2-und-der-kaputte-credentials-manager-ursache-und-workaround-teil-2/

[assarbad]

Losing history on the desktop application is supremely annoying for me, since I mostly use my computers to chat, I rarely use the phone. I sync my desktop and my laptop (docs, project, select application settings), so I have set up my %APPDATA%\Roaming\Signal folder to be synced as well.

Same here.

This used to work fine up until recently and when I synced my laptop a few days ago after coming back from a multi-week trip, I was greeted with this error on my desktop. Now I know why :-) My laptop and my desktop have different DPAPI keys.

Yep, and syncing these with a roaming profile has been known in the past to cause issues. When syncing doesn't work properly you get a similar effect as I do with defunct DPAPI or someone would get where DPAPI is used with the per-machine keys used for storing something in the roaming profile.

The only attack vector I can see where something like this might help would be a malware with just enough access to steal the encrypted data, but now enough access to be able to fetch DPAPI decryption key(s).

Actually once you're running in a user's context you can shoot the respective API calls as needed. No limits. You have full access. This includes malware running in said context.

If you want to keep this approach, would it perhaps be possible to use Signal PIN as the key (or use it to derive a stable key) and use DPAPI to encrypt the PIN? That way, if DPAPI key changes, Signal could prompt the user for the PIN, derive the same key to decrypt the data and re-encrypt the PIN using DPAPI. If you know the PIN, you don't lose your history.

Exactly.

[dosqe]

I have the same problem. Signal is installed in windows profile x. When I log in in profile y and run a program (in my case Joplin) with

runas /user:x /savecred

and after that logout from y and log in again with x, Signal will show the aforementioned error and forces me to delete all data. That is reproducible. It seems it is indeed a problem with DPAPI. Joplin also loses it's encryption key, which I think is also stored via DPAPI.

[scottnonnenberg-signal]

@DOSQue To be very clear - are you seeing DPAPI problems outside of that runas scenario? Like, if you log in as 'user x' and run Signal Desktop and other programs like that, do you have the problems?

[assarbad]

@dosqe you may want to have a look at the DPAPI-related event logs (or even first enable them). Your scenario is somewhat unconventional, because it looks as if you are running something with another user's token (affecting the way DPAPI derives the key) but not necessarily redirecting the way APPDATA and LOCALAPPDATA are accessed. I can see how that may trigger a new key being generated and thereby "breaking the chain" of keys (file is named credhist). Have a look in %APPDATA%\Microsoft\Protect and see if there is more than a single subdirectory. If there is you need to figure out your own SID and the SID of the other account (one way is whoami /all, another is to use regedit to list loaded profiles in HKEY_USERS). If there is more than one, it's already very unusual. If there is one and you can see new keys (sort by timestamp!) that correlate with your runas, it's an issue.

But to be honest that's not the same issue we're having. The symptom is the same, though. And it's the same for the same reason. And you can only start over for the same reason (no way to decrypt the credential used to encrypt the database because you never even saw Signal create that or were able to "guide" it in some way).

[warp-9000]

+1 as I'm also experiencing this issue.

I'm wondering if a work-around would be to setup an Active Directory server at home on my NAS so my Windows profile Master Keys and other Credentials are copied across devices. While overkill, my theory is that this would solve @dosqe's scenario (which is mine as well).