PGP String-to-Key specifiers

Question

I've been reading through the PGP Standard and here I'm a little confused. This section is discussing converting string data to a session key. I'm confused about the paragraph in bold. First off, what does it mean by "hash context"? Secondly, which "data" is it referring to? Is that paragraph still talking about what to do if the hash is too small?

Simple S2K

This directly hashes the string to produce the key data. See below for how this hashing is done.

   Octet 0:        0x00
   Octet 1:        hash algorithm

Simple S2K hashes the passphrase to produce the session key. The
manner in which this is done depends on the size of the session key
(which will depend on the cipher used) and the size of the hash algorithm's output.

If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key.

If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth).

As the data is hashed, it is given independently to each hash context. Since the contexts have been initialized differently, they will each produce different hash output. Once the passphrase is hashed, the output data from the multiple hashes is concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded.

Answer 1

Yes, it's still talking about the case where multiple hashes are needed to get to the key size. Such a function is called a key expand function.

It explains that they are taken independently (different contexts) over the passphrase (the data). A different context means that the calls to the hash functions don't interact; $H$ is seen as a single call to a complete hash function.

For example, with a 160-bit hash (e.g. SHA-1) and a 256-bit key, you would concatenate $H(p)||H(0x00||p)$, then take the leftmost 256 bits (i.e. discard the rightmost 8 octets).

If you needed a third hash block, that would be $H(0x00||0x00||p)$, etc.

Answer 2

Not really disagreeing but to be more specific about context:

In general, crypto hashes (and other hashes for that matter) and symmetric ciphers sometimes need to handle data too large to conveniently put in a single buffer, or fit in memory (especially on small or embedded systems). Thus they are often coded in a way where one routine (function, method, etc) call sets up the initial state, another processes a chunk of data and can be done more than once if there are multiple chunks of data, and a "final" or "done" or "complete" routine produces the result (for hash) or completes and/or verifies the data (padding for block cipher modes, authentication tag for authenticated cipher modes, perhaps others). The internal state that needs to be carried from one routine call to the next is called the context.

As an example, in OpenSSL to MD5 some data you can:

• declare a variable of type MD5_CTX (or malloc space of that size)
• call MD5_Init with the address of the context
• call MD5_Update with the address of the context, and the address and length of some data
• if there is more than one buffer of data, call MD5_Update again as needed
• call MD5_Final with the address of the context, and the address and length where the hash value is stored
• "release" (or free) the context space

For S2K the data being hashed is small enough it's easy to just compute each hash input, and output, directly as in @otus answer. The description in RFC4880 allows for the case where you "start" all the needed hashes, and then run the (passphrase) data into all of them, and then concatenate the outputs. Here that's overkill, but since the purpose of RFCs is to allow different implementations to interoperate, they are careful not to overspecify implementation.