This issue includes #46 and #65 . We want to encrypt the data that is currently in senttxstore.dat , addresslabels.dat and in the SD config file.
We will first focus on brand new SD installs, and require users to set a password to encrypt their local data, just like SDL. Brand new installs are easiest because we don't need to worry about migrating data from the old files, just writing new data in our new format, encrypted, to disk.
To detect if this is the first run of SD, we see if we are going to create a new SD config file on disk. If so, we ask user for a password. If not, then we should have some way for users to click a button in settings to "migrate" old unencrypted data to the new encrypted format.
@fekt if you work on the "new install" stuff and I work on the migration path, I think that will be easiest, since I know about some old weird stuff, such as there actually being two different kinds of addresslabels.dat formats in the past, etc...
I think we should emulate how SDL does things as much as possible. It requires at least a 16 character password and uses Blake3 (which would be a new dependency for SD). Just like SDL, we should store all encrypted data in a single file, instead of multiple files, which makes things more complicated.
TODO
New Installs
Ask user to set passphrase just like SDL
Existing Installs
This issue includes #46 and #65 . We want to encrypt the data that is currently in senttxstore.dat , addresslabels.dat and in the SD config file.
We will first focus on brand new SD installs, and require users to set a password to encrypt their local data, just like SDL. Brand new installs are easiest because we don't need to worry about migrating data from the old files, just writing new data in our new format, encrypted, to disk.
To detect if this is the first run of SD, we see if we are going to create a new SD config file on disk. If so, we ask user for a password. If not, then we should have some way for users to click a button in settings to "migrate" old unencrypted data to the new encrypted format.
@fekt if you work on the "new install" stuff and I work on the migration path, I think that will be easiest, since I know about some old weird stuff, such as there actually being two different kinds of addresslabels.dat formats in the past, etc...
I think we should emulate how SDL does things as much as possible. It requires at least a 16 character password and uses Blake3 (which would be a new dependency for SD). Just like SDL, we should store all encrypted data in a single file, instead of multiple files, which makes things more complicated.
## TODO
* [ ] New Installs
* [ ] Ask user to set passphrase just like SDL
* [ ] Existing Installs
@fekt we can likely use the same .ui files from SDL password screen, with maybe some small modifications. Both SD+SDL both use the same kind of QT GUI XML files to define the interface.
@fekt we can likely use the same .ui files from SDL password screen, with maybe some small modifications. Both SD+SDL both use the same kind of QT GUI XML files to define the interface.
This issue is a lot of work and also is most likely the most important SD issue to work on. I will create a TODO list for this so we can break it up into smaller tasks.
This issue is a lot of work and also is most likely the most important SD issue to work on. I will create a TODO list for this so we can break it up into smaller tasks.
@duke Forgot about this. I can help with the UI if needed. Should be able to port over all the "new wallet wizard" stuff from SDL like you said. Do you want to create a new branch or work off dev?
@duke Forgot about this. I can help with the UI if needed. Should be able to port over all the "new wallet wizard" stuff from SDL like you said. Do you want to create a new branch or work off dev?
duke
This issue includes #46 and #65 . We want to encrypt the data that is currently in senttxstore.dat , addresslabels.dat and in the SD config file.
We will first focus on brand new SD installs, and require users to set a password to encrypt their local data, just like SDL. Brand new installs are easiest because we don't need to worry about migrating data from the old files, just writing new data in our new format, encrypted, to disk.
To detect if this is the first run of SD, we see if we are going to create a new SD config file on disk. If so, we ask user for a password. If not, then we should have some way for users to click a button in settings to "migrate" old unencrypted data to the new encrypted format.
@fekt if you work on the "new install" stuff and I work on the migration path, I think that will be easiest, since I know about some old weird stuff, such as there actually being two different kinds of addresslabels.dat formats in the past, etc...
I think we should emulate how SDL does things as much as possible. It requires at least a 16 character password and uses Blake3 (which would be a new dependency for SD). Just like SDL, we should store all encrypted data in a single file, instead of multiple files, which makes things more complicated.
TODO
@fekt we can likely use the same .ui files from SDL password screen, with maybe some small modifications. Both SD+SDL both use the same kind of QT GUI XML files to define the interface.
This issue is a lot of work and also is most likely the most important SD issue to work on. I will create a TODO list for this so we can break it up into smaller tasks.
@duke I'm interested in helping out with this change.
@jahway603 this is not an easy task but is likely the most important SD issue to work on. If you want to pair on it, let me know
@duke Forgot about this. I can help with the UI if needed. Should be able to port over all the "new wallet wizard" stuff from SDL like you said. Do you want to create a new branch or work off dev?