Keycode Format 1.0 Abstract 1 Format - GitHub

7 downloads 365 Views 157KB Size Report
1.7 The free tag bit. In the specification thus far, the most significant bit ... plays a role in meeting constraint (C)
Keycode Format 1.0

Tom Gibara October 2014

Abstract

LLL LLL LLL LLL LLL LLL NDD

Keycode is an ASCII format for 256-bit keys which aims to reduce the scope for error when sharing keys verbally or via transcription. It provides a number of advantages over the commonplace use of hexadecimal while using fewer characters.

1

LLL LLL LLL LLL LLL LLL NDD

LLL LLL LLL LLL LLL LLL NDD

Figure 1: Tabulation

Format

inserted between every third group and its successor. Conversely, whitespace must not separate the Keycode operates with a 32 byte (256-bit) key com- characters of a triple. The result is 7 rows of 9 bined with a one byte tag which is limited to values characters, split into three groups of three. The output is further constrained so that: in the range 0-127. The role of both the key and tag are application specic, but it is anticipated A) The last row (ie. last 9 characters) consists that the key will be a secure private key of a known only of digits. type; the tag might serve any number of application specic functions, including identifying the key B) None of the triples in the last row begin with type, or distinguishing between multiple keys. a zero. For the purpose of encoding them, the key and the tag are composed into a single 33 byte array C) None of the triples in the last row contain any adjacent digit pairs. with the key occupying the rst 32 bytes and the tag occupying the last byte. The result is a tabular arrangement as indicated in Figure 1, where L indicates an alphanumeric character (Letter or Digit), D indicates a numeric char1.2 Output acter (Digit) and N indicates a non-zero numeric The result of the encoding is a sequence of ASCII character. characters consisting of 1.1

Digits

Input

0-9

Letters

1.3

A-Z excluding

Whitespace

Element Map

The encoding is formed from ve dierent elements.

I,O,S and Z

• A base 32 encoding of key data (B)

HT (tab), LF, CR,

• Alphanumeric checksum characters (C)

of which exactly 63 are not whitespace, with no initial or nal whitespace. The 63 letters and digits are organized into 21 triples. By convention, all triples are separated by whitespace, with newlines

• A custom encoding of 9 bits into 3 digits (9) • A custom encoding of 6 bits into 2 digits (6)

1

BBB BBB BBB BBB BBB BBB 999

BBB BBB BBB BBB BBB BBB 999

BBC BBC BBC BBC BBC BBC 66X

jvk +1 (72 a a < x0 x1 = a + 1 a > x0   v mod 72 where a = 8   b < min(xo , x1 ) b x2 = b + 1 min(xo , x1 ) 6 b < max(xo , x1 ) − 1   b + 2 otherwise x0 =

Figure 2: Encoding Map • A checksum digit (X)

The arrangement of these elements (as indicated by the brackets) is indicated in Figure 2.

where b = v mod 8

Then the mapping v → (x0 , x1 , x2 ) is injective with xi ∈ [0, 9] but x0 6= 1, xo 6= x1 and x1 6= x2 Each B character encodes 5 bits of key data. The yielding the three digits for the encoding. 9 and 6 triples collectively encode that number of data bits. The C and X checksums encode no key 1.5.3 Six Bit Encoding data. Consequently, the capacity of the encoding is precisely 5 × 8 × 6 + 9 × 2 + 6 = 264 bits. This is A similar encoding to that above is used to generate exactly the number of bits required to store a 256 a two digit number from 6 data bits. Given as input bit key and a one byte tag. v ∈ Z with 0 6 v < 64 let: The bits of the key are directly allocated to each jvk element of the encoding: with the most signi+1 x0 = cant bits being encoded in the top-left-most charac(9 ter, and subsequent bits being encoded left-to-right, a a < x0 x1 = top-to-bottom. The tag bits follow directly after, a + 1 a > x0 so that on the last row, the 8 bits of the tag byte where a = v mod 9 are split between the penultimate and last triples. 1.4

Bitmap

1.5

Encodings

1.5.1

Then the mapping v → (x0 , x1 ) is injective with x0 ∈ [1, 9] and x1 ∈ [0, 9] and xo 6= x1 yielding the two digits for the encoding.

Base 32

Most key data is encoded using a simple base 32 encoding. The rst 30 bytes of key data are split into six 5 byte arrays. The 40 bits of each array are then grouped into eight 5 bit integers. These integer values are used in a character-lookup (see A.1) to provide a sequence of eight alphanumeric characters that encode the original 40 bit array.

1.6

Checksums

Every checksum is computed from the row data it terminates using the Damm algorithm1 . Whitespace plays no part in the computation of any checksum. All checksum characters, with the exception of the checksum digit terminating the last row, are 1.5.2 Nine Bit Encoding computed from the 5 bit integers established durA highly specic encoding is used to generate a ing the row encoding (see 1.5.1). This requires a three digit number from 9 data bits such that the totally asymmetric (TA) quasigroup (QG) of order number neither begins with a leading zero, nor in- 32; the construction used is given in an appendix 1 See http://en.wikipedia.org/wiki/Damm_algorithm cludes an adjacent digit pair. Given as input v ∈ Z for an introduction with 0 6 v < 512 let: 2

(see A.3). The resulting checksum value is converted to a character using the same base 32 character map used to encode the key data. The nal checksum is not computed directly from the key data, but from the digits of the last row. Since the digits are limited to the range [0, 9] a TAQG of order 10 is required (this TAQG is tabulated in A.2). The computed checksum is appended to the row using the corresponding ASCII digit.

Checksum computation proceeds using the Damm algorithm: a left fold is performed over the row values using the quasigroup operator with an initial value of zero. In the case of the rst row above, the sequence of values generated is 0, 17, 20, 25, 0, 1, 15, 6, 17. Because the QG used for the 32 bit checksum does not have zeros along its major diagonal, an additional step is required to compute the checksum which consists of nding the inverse w.r.t 0. In this case 17 ∗ 7 = 0, so the checksum value is 7. 1.7 The free tag bit If the tag is set to zero, the remaining 16 key bits, combined with the 8 tag bits, yield the numbers In the specication thus far, the most signicant bit 162, 224 and 0 when split into 9,9,6 bits. Applying (MSB) of the tag byte has not been fully specied the 9 bit encoding given in 1.5.2: and may have been assumed to be zero. This bit plays a role in meeting constraint (C).   Though the specialized encoding dened in X 162 +1=3 x = o avoids generating a digit-pair, when combined the 72 checksum digit to form a triple, a pair may still be   162 mod 72 formed by the check digit and the last digit of the = 2 since 2 < 3 x1 = 8 encoding. x2 = v mod 8 + 2 = 4 since 2 > 2 If this situation occurs, then the MSB of the tag byte is set and the last row encoded again. The So the triple which encodes 162 is (3, 2, 4). Aperror detection capabilities of the Damm algorithm plying the same algorithm to 224 gives (4, 1, 0). Usguarantee that the last digit will change, and since ing the simpler 6 bit encoding on the nal zero value the MSB is encoded in a separate triple, the other gives: digits will not. Thus the digit-pair is guaranteed to have been eliminated.   Note that the status of the tag byte's MSB is 0 xo = +1=1 strictly an encoding concern; the tag value reported 9 by the decoder will not be changed. x1 = 0 mod 9 = 0 since 0 < 1 Thus the nal row (without checksum) consists of the digits 324 410 10. The nal checksum is again obtained via the Damm algorithm, but this Beginning with a randomly generated 256 bit key: time using the order 10 quasigroup of A.2. In this instance, the quasigroup major diagonal is zero, so 8ce970b71df42503a32dc9f64f1df03a the inverse operation unnecessary and the check3d93cb799b3970bebb20b45fd4d95138 sum digit is simply the value obtained by folding; the value sequence is 0, 7, 4, 0, 5, 6, 5, 6, 5 so the Splitting the rst 240 bits of the key into 5 bit checksum digit is 5. words provides the values needed to compute the In this case the nal checksum digit does not checksums for the rst 6 rows (underlined below). create a digit pair, so the computed last row stands. Applying the character mapping in A.1, appending 17 19 20 23 1 13 24 29 7 the last row and inserting group spacing gives the 30 16 18 16 7 8 25 13 30 formatted key data.

2

Example

25 7 27 4 30 7 8 30 25 7 19 12 28 23 1 4 2 26 5 31

7 18 15 21

15 27 21 6

16 25 27 25

17 24 31 2

HKL P1D QW7 XGJ G78 RDX R7U 4X7 FGH

3

78X KCV 42T 324

A

Base 32 Character Map

1 9 H R

A.2

0 1 2 3 4 5 6 7 8 9 A.3

URQ MUY 6R2 105

Appendix

A.1

0 8 G Q

R7J P1F 5YM 410

2 A J T

3 B K U

4 C L V

5 D M W

6 E N X

7 F P Y

Order 10 TA Quasigroup

0 0 7 4 1 6 3 5 8 9 2

1 3 0 2 7 1 6 8 9 4 5

2 1 9 0 5 2 7 6 4 3 8

3 7 2 6 0 3 4 9 5 8 1

4 5 1 8 9 0 2 7 3 6 4

5 9 5 7 8 4 0 2 6 1 3

6 8 4 1 3 5 9 0 2 7 6

7 6 8 3 4 9 5 1 0 2 7

8 4 6 5 2 7 8 3 1 0 9

9 2 3 9 6 8 1 4 7 5 0

Order 32 TA Quasigroup construction

The Keycode format uses a TAQG derived from GF (32). Let F be that eld constructed using the irreducible polynomial x5 + x2 + 1. A quasigroup G = (F, ∗) may then be constructed by dening: a ∗ b = xa + b

Elements of Z52 are mapped to F by (b0 , b1 , b2 , b3 , b4 ) →

X

bi x i

i

When regarded as a binary mapping, b0 corresponds to the least signicant binary digit.

4