If I use TOTP to generate codes with different "expiration" time, using the same key for HMAC, will I create some kind of weakness?
Yes, that's fine where TOTPs are generated in accordance with RFC 6238; this is because the time is combined with the secret before generating the HMAC. This means that it isn't practically possible to derive the time (or information about it, such as the time difference) based on the key alone because of the Avalanche effect in the hashing algorithm that is used.
It's not really clear what you're trying to do, so I cannot give a definitive answer. But the default answer, in the absence of more details that you've provided, is that whatever you're doing, it probably isn't secure.
Specifically, TOTP (RFC 6238) keys are generated from two inputs:
- a fixed secret key, and
- an incremental counter, counting the number of (arbitrary) time steps elapsed since an (arbitrary) starting epoch.
While you could, in principle, choose epoch and time step values for two counter sequences so that the counter values will not overlap in the foreseeable future, this is not how TOTP is meant to be used. In fact, there are TOTP implementations that will not even let you change the epoch or the time step from the default values.
Rather, the proper and secure way to ensure that two TOTP output sequences will not overlap (in order to e.g. generate distinct passwords for different purposes) is to use separate secret keys for them.
Note that, for some purposes, it may be convenient to derive the separate keys from a single master key using a key derivation function, such as HKDF (RFC 5869), which is based on the same cryptographic tools (hash functions and HMAC) as TOTP is. For example, if you had a server that needed to authenticate with many clients, without storing a separate TOTP key for each of them, you could derive each client key from a master key stored on the server, allowing the server to re-derive the client keys as needed.