For iteration-0, CFB (or some other feedback mode)-encrypt the passphrase from the input buffer to the output buffer (assuming the library doesn't require that the plaintext and ciphertext be in the same buffer)
This doesn't work because the input and output buffer will almost always be of different lengths.
Questions: Are you using the previous chaining-variables/hash for each successive chunk?
No. Each chunk is a new hash with <whatever>, where <whatever> defaults to SHA1. Since (for SHA1) 64 bytes of input affect each 20 bytes of output, I don't think there's much need for chaining. I'm trying to keep the specification as simple and easy to check as possible (one of the problems with the PGP data management was that it was rather complex and hard to follow. I suspect it would be difficult to implement a compatible version going only from a written specification).
How do you pad passphrases that are smaller than the minimum input for a hash function?
The input wraps, just like the output, so for example the letter "a" would be hashed as: <length>a<length>a<length>a<length>a<length>a<length>a[...]
Hash the user's input, prepended with a 0x00. Use this for the first 0..160 bits of key. If more than 160 bits is needed, write over the 0x00 with 0x01. Hash again. This is much like your solution, but no wrapping. Note there is no problem truncating hash output.
That's another possibility. The only thing here is that you're only changing one byte for each pass, and I'm not sure if this is healthy. I'll see what the sci.crypt crowd (those who've survived the spamming) has to say about this - it may actually be stronger than my increment-by-one method if you're worried about related-key cryptanalysis. Peter.