The size of the padding could be made public, if you don't mind leaking some additional information about the plaintext size. Using a hash as padding bytes however does not make sense; you can not use the hash as authentication tag or to check the integrity, so the hash calculation becomes spurious. It may even leak data through a side channel. In the best case it simply eats CPU resources without accomplishing anything.
It is better to use a vetted padding method such as PKCS#7 or bit padding. They may use a block of ciphertext more, but otherwise the implementation light on resources. Both padding methods are however vulnerable to padding oracle attacks. So you should generate a MAC or HMAC (using a second key) over the ciphertext. You should include all public information in the MAC calculation as well.
Alternatively you could use zero byte padding and a padding or plain text length indicator byte as this may save you a block of bytes to encrypt. In that case you should definitely include the length indicator in the MAC calculation as an attacker could otherwise fool you into adding or removing bytes from the plain text by simply changing the length indicator.
Finally you could of course use a block cipher in counter mode, possibly using an authenticated scheme such as GCM. This would rid you of padding altogether (the plaintext size is the ciphertext size) and would generate a message authentication tag without having to resort to two separate keys. As in the MAC calculation you should include all public data as additional authenticated data (AAD). Furthermore, you should be sure never to repeat the nonce/IV. You would not need a separate nonce and IV either.