quick update (i need to review the code some more, but this is slipping down the page and i need to go do some errands) - i have fixed all the above, i believe.

quick update (i need to review the code some more, but this is slipping down the page and i need to go do some errands) - i have fixed all the above, i believe. the salt is now 128 bits of random data, included with the message (and covered by the HMAC, along with the header). HMACs are compared using a second hash. the counter is 1/2 a block of random nonce (taken from the salt) and 1/2 a block of incremented counter, as described in the NIST docs (their second option in section B2 of http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a...). the message includes a 4 byte header that is checked on decryption (in general, the code includes a bunch more checks and exceptions). PBKDF2 now explicitly uses SHA256 (you were right; the default was SHA1). thank-you again! ps just fyi (i am not using it, but stumbled across this while checking things again) wraparound does seem to be ok - the standard incrementing function in section B2 is "mod 2^m" (so wraps; the example given actually includes a wrap!). but still, they recommend a separate nonce and incrementing block (rather than incrementing from a random offset) (which is what i have changed to).