slip39: more wip changes

slip-0039.md

@@ -43,9 +43,18 @@ From this value the N parts are generated and each participating party receives
 
 | 00 | 4-bit index | 4-bit M threshold | variable-bit SSSS part | 16-bit checksum |
 
-The index corresponds to the SSSS part's x value (see the diagram above) and the SSSS part is the corresponding y value. Finally, the checksum field is a CRC-16 (CRC-CCITT polynomial x^16 + x^12 + x^5 + 1, often represented as 0x1021) checksum of both the index and the Shamir part. N is not included.
+The index corresponds to the SSSS part's x value (see the diagram above) and the SSSS part is the corresponding y value. Finally, the checksum field is a checksum of both the whole share (including padding zeroes, index and threshold, N is not included).
 
-This structure is then converted into a mnemonic passphrase by splitting it up by 10 bits which correspond as an index to the a word list containing exactly 1024 words.
+This structure is then converted into a mnemonic passphrase by splitting it up by 10 bits which correspond as an index to the a word list containing exactly 1024 words (see below).
+
+| master secret | SSSS part | share length           |
+|---------------|-----------|------------------------|
+| 128 bits      | 144 bits  | 170 bits = 17 words    |
+| 256 bits      | 272 bits  | 298 bits = 30 words    |
+
+## Checksum
+
+For checksum we use lower 16-bits of CRC32 algorithm. We don't use CRC16, because there are lots of different standards and CRC32 has much higher chance to be implemented in the standard library of your choice. Also we won't need 32-bit resolution and this would lead to more words in the shares.
 
 ## Passphrase
 
@@ -55,6 +64,8 @@ When enough M secrets are provided the master secret is reconstructed. To allow
 
 This mechanism is intentionally symmetric to allow reconstructing the master secret from the seed in case the passphrase is known.
 
+TODO: We propose to use (X) rounds of PBKDF2 and (Y) rounds of AES (which mode?).
+
 ## Versioning
 
 Our scheme doesn't support versioning. This is intentional to avoid unclear claims such as SLIP-0039 compatibility without a clear understanding, which version of the scheme is actually meant. We encourage creating a new document for any new improvements. Since the master secret is easily retrievable, migration to a new scheme is trivial.