3.7. String-to-Key (S2K) Specifiers String-to-key (S2K) specifiers are used to convert passphrase strings into symmetric-key encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert p
| 725 | |
| 726 | |
| 727 | class String2Key(Field): |
| 728 | """ |
| 729 | 3.7. String-to-Key (S2K) Specifiers |
| 730 | |
| 731 | String-to-key (S2K) specifiers are used to convert passphrase strings |
| 732 | into symmetric-key encryption/decryption keys. They are used in two |
| 733 | places, currently: to encrypt the secret part of private keys in the |
| 734 | private keyring, and to convert passphrases to encryption keys for |
| 735 | symmetrically encrypted messages. |
| 736 | |
| 737 | 3.7.1. String-to-Key (S2K) Specifier Types |
| 738 | |
| 739 | There are three types of S2K specifiers currently supported, and |
| 740 | some reserved values: |
| 741 | |
| 742 | ID S2K Type |
| 743 | -- -------- |
| 744 | 0 Simple S2K |
| 745 | 1 Salted S2K |
| 746 | 2 Reserved value |
| 747 | 3 Iterated and Salted S2K |
| 748 | 100 to 110 Private/Experimental S2K |
| 749 | |
| 750 | These are described in Sections 3.7.1.1 - 3.7.1.3. |
| 751 | |
| 752 | 3.7.1.1. Simple S2K |
| 753 | |
| 754 | This directly hashes the string to produce the key data. See below |
| 755 | for how this hashing is done. |
| 756 | |
| 757 | Octet 0: 0x00 |
| 758 | Octet 1: hash algorithm |
| 759 | |
| 760 | Simple S2K hashes the passphrase to produce the session key. The |
| 761 | manner in which this is done depends on the size of the session key |
| 762 | (which will depend on the cipher used) and the size of the hash |
| 763 | algorithm's output. If the hash size is greater than the session key |
| 764 | size, the high-order (leftmost) octets of the hash are used as the |
| 765 | key. |
| 766 | |
| 767 | If the hash size is less than the key size, multiple instances of the |
| 768 | hash context are created -- enough to produce the required key data. |
| 769 | These instances are preloaded with 0, 1, 2, ... octets of zeros (that |
| 770 | is to say, the first instance has no preloading, the second gets |
| 771 | preloaded with 1 octet of zero, the third is preloaded with two |
| 772 | octets of zeros, and so forth). |
| 773 | |
| 774 | As the data is hashed, it is given independently to each hash |
| 775 | context. Since the contexts have been initialized differently, they |
| 776 | will each produce different hash output. Once the passphrase is |
| 777 | hashed, the output data from the multiple hashes is concatenated, |
| 778 | first hash leftmost, to produce the key data, with any excess octets |
| 779 | on the right discarded. |
| 780 | |
| 781 | 3.7.1.2. Salted S2K |
| 782 | |
| 783 | This includes a "salt" value in the S2K specifier -- some arbitrary |
| 784 | data -- that gets hashed along with the passphrase string, to help |
no outgoing calls
searching dependent graphs…