Counter based cipher using HMAC-SHA-256 After trying to invent my own AES mode, I decided to just implement something that's known to work, namely CTR mode with HMAC-SHA-256.

From what I understand, I can use the IV as a counter, and the IV only has to be unique for each key (generating unique IVs isn't a problem). Correct?

Is it a problem for HMAC-SHA-256 if I construct a SHA block using a 32 byte key, 16 byte counter and 16 zero bytes for padding, or is it better to generate a 64 byte key so it fits in one SHA block and make another block for the counter and pad that block with zero bytes?

If I want to add a salt to anything, I assume the salt is stored unencrypted. Correct?


Edit for clearing up some things:
Using the IV as a counter implies that it changes for each encrypted block. In this case I'll use a simple time stamp directly from the OS that's 12 bytes large (resolution is in ticks, which are 1/50th of a second, software waits one tick before generating an IV, system is slow so not a problem). The remaining four bytes are used as a block counter (simply starts at zero).
The intended HMAC setup is:
The first SHA-256 message is made of the first HMAC key, the IV, padding and the cipher text. The first SHA-256 block will be the first HMAC key (32 bytes), then the 16 byte IV, then 16 bytes of zero padding. The remaining blocks for the message are cipher text blocks, with normal SHA padding after the last cipher text block (normal SHA operation). The resulting hash is the first HMAC hash.
The second SHA-256 message is the second HMAC key (32 bytes) and then the first HMAC hash (32 bytes), with the normal SHA padding at the end. This is the authentication tag.
Second edit:
After searching the web some more, I found that I made some assumptions about the way the HMAC keys are used. I've used some test vectors from NIST to verify that I'm doing things properly, and that's now the case.
Proper HMAC-SHA-256 setup:
Take first 32 byte HMAC key, append 32 zero bytes, XOR IPAD over the resulting 64 byte block, append cipher text, hash.
Take second 32 byte HMAC key, append 32 zero bytes, XOR OPAD over the resulting 64 byte block, append first hash, hash.
I assume you can prepend the nonce to the cipher text so it gets hashed as well. Correct?
From what I understand, I can use the IV as a counter, and the IV only has to be unique for each key (generating unique IVs isn't a problem). Correct?

Not exactly. The IV needs to be unique for each block per key. You can use a message counter for the Nonce component of the IV, then the block counter component is incremented from 0 in CTR.
IV = [96-bit Message NONCE][32-bit Block COUNTER]

Since the Nonce does not to be random or unpredictable, a message counter is appropriate. I use a combination of message counter, time code, and random number, all 32-bits, which helps against accidental nonce reuse if the counter gets maliciously reset. The key needs to be changed before the message counter overflows.
IV = [32-bit RANDOM][32-bit Timecode][32-bit Message CTR][32-bit Block CTR]

There are other methods that can be used. You may not want timecode information to be sent with a message, or have an attacker know how many messages you have sent. You can even encrypt the nonce with another key before using it in CTR mode, but you will need a custom setup for that because it can be done VERY wrong and break security.

Is it a problem for HMAC SHA256 if I construct a SHA block using a 32 byte key, 16 byte counter and 16 zero bytes for padding, or is it better to generate a 64 byte key so it fits in one SHA block and make another block for the counter and pad that block with zero bytes?

That will change how HMAC operates, which is to only have the key as the key input. HMAC per spec will only hash the key input if it is larger than the blocksize, so you can input 512-bits of &quot;key&quot; data, although it is not necessary to include a counter as part of the input. Appending the nonce to the key should not have any negative effect on security, it may even strengthen it, but I will not say that with any certainty. It is probably better to prepend the nonce to the message input if you want it to be authenticated, rather than adding it to the key. Including the counter with the key also eliminates a specific kind of performance optimization you can use.
You may want to consider SHA-512/256 or SHA-3-256 instead. If you have 64-bit code and CPU available it is faster, and should be more secure against current and unknown attacks. MAC using SHA3 is different, it prepends the message with the key.

If I want to add a salt to anything, I assume the salt is stored unencrypted. Correct?

A salt is a non-secret piece of cryptographic information, so it does not need to be encrypted. You may want to add some kind of redundancy check or rebuild parity (such as Reed-Solomon) to be associated with it, if you feel there is a chance it can be altered accidentally. Keep a backup somewhere, a password without the salt will mean a lost key.
Finally, make sure you are using different keys for your cipher and your MAC. The reason is that an attack on one of them can break both. While that may be unlikely, it is still a good idea to use separate keys, and is FIPS compliant.