From 4e4b04c48dc57d08a881c3281c02ee182f1ec674 Mon Sep 17 00:00:00 2001 From: kngako Date: Fri, 25 Jun 2021 15:18:27 -0700 Subject: [PATCH] Update 'src/profile_encryption_and_storage.md' --- src/profile_encryption_and_storage.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/profile_encryption_and_storage.md b/src/profile_encryption_and_storage.md index 5914b28..f92929a 100644 --- a/src/profile_encryption_and_storage.md +++ b/src/profile_encryption_and_storage.md @@ -1,6 +1,6 @@ # Profile Encryption & Storage -Profiles are stored on locally on disk and encrypted using a key derived from user-known password (via pbkdf2). +Profiles are stored locally on disk and encrypted using a key derived from user-known password (via pbkdf2). Note that once encrypted and stored on disk, the only way to recover a profile is by rederiving the password - as such it isn't possible to provide a full list of profiles a user might have access to until they enter a password. @@ -10,6 +10,8 @@ it isn't possible to provide a full list of profiles a user might have access to To handle profiles that are "unencrypted" (i.e don't require a password to open) we currently create a profile with a [defacto, hardcoded password](https://git.openprivacy.ca/cwtch.im/libcwtch-go/src/branch/trunk/constants/globals.go#L5). + + This isn't ideal, we would much rather wish to rely on OS-provided key material such that the profile is bound to a specific device, but such features are currently patchwork - we also note by creating an unencrypted profile, people who use Cwtch are explicitly opting into the risk that someone with access to the file system may be able to decrypt