@@ -21,3 +21,68 @@ Glossary
21
21
ECDH
22
22
Elliptic Curve Diffie-Hellman
23
23
24
+ raw encoding
25
+ Conversion of public, private keys and signatures (which in
26
+ mathematical sense are integers or pairs of integers) to strings of
27
+ bytes that does not use any special tags or encoding rules.
28
+ For any given curve, all keys of the same type or signatures will be
29
+ encoded to byte strings of the same length. In more formal sense,
30
+ the integers are encoded as big-endian, constant length byte strings,
31
+ where the string length is determined by the curve order (e.g.
32
+ for NIST256p the order is 256 bits long, so the private key will be 32
33
+ bytes long while public key will be 64 bytes long). The encoding of a
34
+ single integer is zero-padded on the left if the numerical value is
35
+ low. In case of public keys and signatures, which are comprised of two
36
+ integers, the integers are simply concatenated.
37
+
38
+ uncompressed
39
+ The most common formatting specified in PKIX standards. Specified in
40
+ X9.62 and SEC1 standards. The only difference between it and
41
+ :term: `raw encoding ` is the prepending of a 0x04 byte. Thus an
42
+ uncompressed NIST256p public key encoding will be 65 bytes long.
43
+
44
+ compressed
45
+ The public point representation that uses half of bytes of the
46
+ :term: `uncompressed ` encoding (rounded up). It uses the first byte of
47
+ the encoding to specify the sign of the y coordinate and encodes the
48
+ x coordinate as-is. The first byte of the encoding is equal to
49
+ 0x02 or 0x03. Compressed encoding of NIST256p public key will be 33
50
+ bytes long.
51
+
52
+ hybrid
53
+ A combination of :term: `uncompressed ` and :term: `compressed ` encodings.
54
+ Both x and y coordinates are stored just as in :term: `compressed `
55
+ encoding, but the first byte reflects the sign of the y coordinate. The
56
+ first byte of the encoding will be equal to 0x06 or 0x7. Hybrid
57
+ encoding of NIST256p public key will be 65 bytes long.
58
+
59
+ PEM
60
+ The acronym stands for Privacy Enhanced Email, but currently it is used
61
+ primarily as the way to encode :term: `DER ` objects into text that can
62
+ be either easily copy-pasted or transferred over email.
63
+ It uses headers like ``-----BEGIN <type of contents>----- `` and footers
64
+ like ``-----END <type of contents>----- `` to separate multiple
65
+ types of objects in the same file or the object from the surrounding
66
+ comments. The actual object stored is base64 encoded.
67
+
68
+ DER
69
+ Distinguished Encoding Rules, the way to encode :term: `ASN.1 ` objects
70
+ deterministically and uniquely into byte strings.
71
+
72
+ ASN.1
73
+ Abstract Syntax Notation 1 is a standard description language for
74
+ specifying serialisation and deserialisation of data structures in a
75
+ portable and cross-platform way.
76
+
77
+ bytes-like object
78
+ All the types that implement the buffer protocol. That includes
79
+ ``str `` (only on python2), ``bytes ``, ``bytesarray ``, ``array.array ``
80
+ and ``memoryview `` of those objects.
81
+ Please note that ``array.array `` serialisation (converting it to byte
82
+ string) is endianess dependant! Signature computed over ``array.array ``
83
+ of integers on a big-endian system will not be verified on a
84
+ little-endian system and vice-versa.
85
+
86
+ set-like object
87
+ All the types that support the ``in `` operator, like ``list ``,
88
+ ``tuple ``, ``set ``, ``frozenset ``, etc.
0 commit comments