Mirrors
/
open-keychain
mirror of https://github.com/open-keychain/open-keychain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Backups (markdown)

Dominik Schürmann 2016-01-06 13:13:32 +01:00
parent 894d64dd7b
commit 9dcaabe4c0
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
Backups.md

@ -10,15 +10,24 @@ In OpenKeychain, backups are encrypted using:
This is work in progress...
##Changelog
* change to chunking of 4 characters
Example: ``TWNK-KDEY-MTWT-EVGS-DRDB-KVTW``
## Standard
* A backup consists of 24 upper case characters from the Latin alphabet grouped into 4-character chunks, e.g., ``TWNK-KDEY-MTWT-EVGS-DRDB-KVTW``. The characters are generated from secure random. The whole backup code including the dashes is used as a string to directly encrypt an OpenPGP message (more precisely: It is used as the symmetric-key for a [Symmetric-Key Encrypted Session Key Packet](http://tools.ietf.org/html/rfc4880#section-5.3), the symmetric-key is thus 29 characters long including the dashes).
* The encryption algorithm is one of the standardized OpenPGP symmetric algorithms (in case of OpenKeychain: AES-256)
## Saved as a file
* When saving backups as a file ASCII armor MUST be used and a special header MUST be added: ``BackupVersion: 2``
* This way implementations can check if it is a backup and a special dialog for entering backup codes can be shown instead of a dialog with single text fields for entering passwords.
* The header does not automate anything, it poses no additional security threat.
## Saved in other storages
* When saving in other storages, such as private XMPP storages, ASCII armor is not required. Thus, the ASCII armor header can not be used. To show a special dialog, the implementation must know that the file came from a special storage and is a backup
## Design decisions
* A backup consists of 24 upper case characters from the alphabet. It is generated from secure random and then used directly for encrypting an OpenPGP message (more precisely: It is used for the [Symmetric-Key Encrypted Session Key Packet](http://tools.ietf.org/html/rfc4880#section-5.3)). The whole backup code, e.g., ``TWNK-KDEY-MTWT-EVGS-DRDB-KVTW`` (including the dashes -> 29 characters long), is used as a symmetric-key. Dashes are included to ease decryption using OpenPGP implementations that don't offer special dialogs for entering backup codes and only support single text fields for entering passwords.
* Dashes are included to ease decryption using OpenPGP implementations that don't offer special dialogs for entering backup codes and only support single text fields for entering passwords.
* Security level: Possible combinations are 26^24 = 2^112.8. This is enough to be protected against offline brute force attacks.
* The encryption algorithm is one of the standardized OpenPGP symmetric algorithms (in case of OpenKeychain: AES-256)
* Using only upper case letters, no lower case letters and no numbers
* Using mixed upper and lower case makes it much more difficult to recall the characters from short term memory. Consider someone reading them aloud, it is required to say for every letter if it's upper or lower case. Memorizing things in short term memory works similar to reading something aloud, which makes the mixed upper/lower case backup codes double as difficult to remember than upper-case-only backup codes.
* Numbers would increase the alphabet by only 10 characters, the length of the backup code would be only 2 characters shorter to achieve the same security.
@ -34,11 +43,3 @@ Example: ``TWNK-KDEY-MTWT-EVGS-DRDB-KVTW``
* I haven't found studies targetting this special use case in computer science, but some target similar ones, but only considering long term memory:
* [2015, Jun Ho Huh et al.: On the Memorability of System-generated PINs: Can Chunking Help?](http://lersse-dl.ece.ubc.ca/record/304/files/soups2015-final110.pdf)
* [2006, Deborah S. Carstens, Linda C. Malone, Pamela McCauley-Bell: Applying Chunking Theory in Organizational Password Guidelines](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.97.2782&rep=rep1&type=pdf)
## Saved as a file
* When saving backups as a file ASCII armor MUST be used and a special header MUST be added: ``BackupVersion: 2``
* This way implementations can check if it is a backup and a special dialog for entering backup codes can be shown instead of a dialog with single text fields for entering passwords.
* The header does not automate anything, it poses no additional security threat.
## Saved in other storages
* When saving in other storages, such as private XMPP storages, ASCII armor is not required. Thus, the ASCII armor header can not be used. To show a special dialog, the implementation must know that the file came from a special storage and is a backup