nurupo / ProjectTox-Qt-GUI

A cross-platform front end for ProjectTox Core library, written in C++11 with use of Qt5
GNU General Public License v3.0
343 stars 117 forks source link

Data file encryption #66

Open nurupo opened 11 years ago

nurupo commented 11 years ago

Toxcore provides an unencrypted data buffer that can be saved to a file and loaded back next time Toxcore is run. Since the buffer contains an unencrypted data, it was decided to encrypt it before writing to a file. The file should contain an unencrypted identifier — either username, pubic id (not very user-friendly) or an account name unrelated to the username, which will be shown in the Login Dialog so that user can differentiate between different accounts and pick the needed one.

There has been a discussion on making a common data file format so that it would work across different tox clients, but it didn't go far. There is a repo which aims to provide an encrypted data serialization library for client applications to use, so that client writers wouldn't need to implement the same algorithm in their clients. There is also a draft of a data file format here.

The data file encryption is to be written in C in this repo, based on the draft of the data file format mentioned above (revise the draft if needed). The encryption should use NaCl library, since that's the encryption library Toxcore uses, so it's always present.

UPDATE 2014-01-04: encrypted versions of save/load functions were added to the Toxcore https://github.com/irungentoo/ProjectTox-Core/commit/c51b8a9eba2b7f50f34796f9606c4cb7322993fa It stores keys, DHT, friends and a username. Status message will be added later. So, basically, there seem to be no need of writing any additional library. The only place for improvement is to include bootstrap nodes in Toxcore's data file, so that it would be shared among clients. Other client-specific settings can be stored in a separate file encrypted the same way Toxcore encrypts its data file. The client already stores settings in a settings.ini, so it should just get encrypted.

UPDATE 2014-01-05: After a discussion between @irungentoo and @jencka, they agreed that the encryption currently used in Toxcore's save/load is too fast, hence vulnerable to bruteforce/dictionary attacks (save doesn't use a key-derivation algorithm). As a result, @irungentoo suggested changing the encryption algorithm use in Toxcore's encrypted save/load to what @jencka have used in #90 (scrypt), but because the encrypted save/load is optional and @irungentoo didn't want to introduce an additional encryption library dependency for it, he suggested making a small separate library for clients to use.