How secure is SHA256 when input size is not 512 bits?

[potatobad]

So if I understand correctly bitcoin performs a hash on a 256 bit ecdsa public key, do you still have a 256 bit protection when the input is not 512 bit? Isnt the compression function security based on compressing 2 to 1?

[1714705620]

1714705620

[1714705620]

1714705620

[1714705620]

1714705620

[pooya87]

security of a hash algorithm is defined by its output size and the algorithm itself not by its input size. SHA256 provides 128-bits of security.
by the way the hash that you are referring to is RIPEMD160 of SHA256 of the public key and it is only used in transaction outputs so that we don't reveal the public key until that output is to be spent. and the size of the "input" is defined by the elliptic curve that bitcoin uses so it is always 256 bit and there is no way around it.

[odolvlobo]

So if I understand correctly bitcoin performs a hash on a 256 bit ecdsa public key, do you still have a 256 bit protection when the input is not 512 bit? Isnt the compression function security based on compressing 2 to 1?

A compressed key is just the first half of the uncompressed key. Because the second half of an uncompressed public key is (almost) completely determined by the first half, it gives you no additional security.

[potatobad]

security of a hash algorithm is defined by its output size and the algorithm itself not by its input size.

Ok you hash a fixed 16 bit input with sha256 and ill find it in a second

[pooya87]

security of a hash algorithm is defined by its output size and the algorithm itself not by its input size.

Ok you hash a fixed 16 bit input with sha256 and ill find it in a second

that would be brute forcing which has nothing to do with security of SHA256. and the answer to your original question is "it is less secure if you use 16 bits instead of 512 bits input".
but since your original question is about 256 bit versus 512 bit input, brute force is not an option there since 256 bit is still big enough to make it impossible.