I am not entirely sure I got your question right, so let me rephrase it: you want a function $H$, that takes as inputs strings of bits, and outputs other strings of bits, such that:
- There is nothing secret in $H$; it is deterministic, easily computable, and uses no secret key.
- If $m$ has length $k$ bits, then $H(m)$ also has length exactly $k$ bits.
- It should be computationally hard to find two distinct inputs $m$ and $m'$ (with the same common length $k$ bits) such that $H(m) = H(m')$. The "hardness" here means that the effort to find a collision should be at least in $O(2^{k/2})$.
With these requirements, a very simple solution is to use the identity, i.e. $H(m) = m$ for all strings $m$. The identity can be computed very efficiently: it has cost zero. There are no collisions at all, so the hardness of finding a collision is infinite. However, I suppose that the identity is not appropriate in your use case; i.e. you actually want more than just "resistance to collisions".
So let's add some extra requirements. You want a publicly computable function $H$ that preserves length ($H(m)$ has the same length, in bits, as $m$, for all strings $m$), and that fulfill the three classical notions of security for hash functions:
- Resistance to preimages: given output $t$, it should be computationally hard to find input $m$ such that $H(m) = t$.
- Resistance to second preimages: given input $m$, it should be computationally hard to find input $m'$ such that $m\neq m'$ but $H(m) = H(m')$.
- Resistance to collisions: given a bit length $k$, it should be computationally hard to find inputs $m$ and $m'$ of length $k$ bits, such that $m\neq m'$ but $H(m) = H(m')$.
Note that, in our case, we must use the bit length as parameter. In usual hash function, the input length is arbitrary but the output length is fixed an implicit in the definition of the hash function. For your function $H$, you must add the bit length $k$ as parameter to the security notions. For preimages and second preimages, this is easily obtained as the length of the challenge: when I give you $t$ and challenge you to find $m$ such that $H(m) = t$, then I also necessarily give you the bit length $k$, which is the length of $t$. But for the "collisions" challenge, I must specify the bit length $k$ explicitly, otherwise you could (smugly) solve the problem for a very short length, and show me that collision.
The variable-length property of $H$ makes the problem a bit harder to analyze. With a normal hash function with a fixed output size ($k$ bits), but accepting inputs of arbitrary sizes, it can be shown that the best resistances you can hope for are on the order of $2^k$ for preimages and second preimages, and $2^{k/2}$ for collisions. However, with a length-preserving function, you can get farther some of these limits; indeed, if you use the identity (i.e. $H(m) = m$), then resistance to preimages is nil (simply set $t = m$) but resistance to second preimages and collisions is infinite (there is simply no collision at all).
All of that being said, an easy solution is to use a key derivation function. One standard KDF is HKDF: it can take inputs of arbitrary size, and produce outputs of configurable size, so you can simply use HKDF with an output size equal to the input size. This has some caveats, though:
Maximum output size of HKDF is limited to 255 times the output size of the underlying hash function. If you build HKDF over SHA-256, then you will get an output of at most 8160 bytes (65280 bits).
You will heuristically get your collision resistance target ($2^{k/2}$) but, again, only up to some limit. If the internal hash function is SHA-256, then for $k \gt 256$, you might not get more than $2^{128}$ resistance to collisions. This does not matter in practice, since anything beyond about $2^{100}$ is equivalent to infinite for the foreseeable future.
Another candidate is SHAKE, one of the variants of SHA-3. SHA-3 is based on Keccak, a "sponge function" in which you first accumulate the input into an internal state, then produce output from that state; with "plain" SHA-3 you just get enough bits to reach the defined output size for the hash function, but with SHAKE you let it flow for as long as you want. If you define $H$ to be "SHAKE256, with an output size equal to the input size", then you should get a reasonable solution. Note that SHAKE output size is not practically limited; however, like with HKDF, there is an internal limit which will set a maximum to the collision resistance you can hope for, in a theoretical point of view.
(Having such a limit is mostly necessary for any function that works but first absorbing the data into an internal fixed-size state, then producing output deterministically from that state alone. This should not be a problem in practice, since you can put that limit far away into the land of "cannot do that in practice". If you want to talk theory with adversaries of truly unlimited power, then take care that there is no known proof that secure hash functions can actually exist at all.)
