34 Backups

Dominik Schürmann edited this page 2016-02-10 19:24:05 +01:00

Unescape Escape

Table of Contents

• Backup Format v2
• Saved as a file
• Saved in other storages
• Design decisions
• Diff to Version 1
• Deprecated Version 1

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Backup Format v2

1. All secret and public keys that should be included in the backup MUST be concatenated in their transferable key format.
2. A backup code is generated from secure random: The backup code consists of 24 upper case characters from the Latin alphabet and numbers without O and 0 (123456789ABCDEFGHIJKLMNPQRSTUVWXYZ) grouped into 4-character chunks, e.g., TWNK-KD5Y-MT3T-E1GS-DRDB-KVTW. The characters MUST be generated from secure random, such as /dev/urandom.
3. The whole backup code including the dashes is directly used as a string to encrypt the concatenated transferable keys as an OpenPGP message (more precisely: It is used as the symmetric-key for a Symmetric-Key Encrypted Session Key Packet, the symmetric-key is thus 29 characters long including the dashes). The encryption algorithm MUST be 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 ASCII armor 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 MUST NOT automate anything, it should only have an impact on the UI.

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

• 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 34^24 = 2^122.10. This is enough to be protected against offline brute force attacks. You can get a rough estimate using https://www.grc.com/haystack.htm .
• Using only upper case letters, no lower case letters
  • 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.
  • They look like serial numbers, like they were used for Windows, when using upper case only. Many people know serial numbers and are thus comfortable with using these.
• Dividing into 4-character chunks
  • The following studies are great background, why chunking into 4 characters makes most sense, especially the last publication:
    • 1986, Richard Schweickert, Brian Boruff: Short-Term Memory Capacity: Magic Number or Magic Spell?
    • 1994, George A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information
    • 2000, Nelson Cowan: The magical number 4 in short-term memory: A reconsideration of mental storage capacity
    • 2011, Fabien Mathy, Jacob Feldman: What’s magic about magic numbers? Chunking and data compression in short-term memory
  • According to the last publication: Our backup codes are uncompressable (cf. Figure 1 sequence 3 in the paper) because they normally include no pattern. Thus, only 4 characters can be recalled in a usable way with short term memory.
  • 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?
    • 2006, Deborah S. Carstens, Linda C. Malone, Pamela McCauley-Bell: Applying Chunking Theory in Organizational Password Guidelines

Diff to Version 1

• Change to 4 characters chunks instead of 6 character chunks
• Include numbers

Deprecated Version 1

• AES-256 (because this is default for all encrypted files in OpenKeychain)
• Passphrase is securely generated from random by OpenKeychain and based on 24 uppercase characters, separated with dashes into 4*6 character chunks. Thus, the passphrase is 27 characters long, example: ABCDEF-GHIJKL-MNOPQR-STUVWX.
• Possible combinations are: 26^24 = 2^112.8
• The backup file is ASCII armored and a special header is added: BackupVersion: 1