Ambiguity between v3, v4, and v5 signatures.

It appears to be almost possible to re-interperet a v4 signature as a v5 signature (of different data). The only limitation is that the hashed data length cannot exceed 4GiB, as there is no way to encode a signature packet of such size.

What really stops this attack is that the trailers differ. The last five bytes of hashed data for a v3 signature are type 4-byte timestamp. The last six bytes for a v4 signature are 0x04 0xFF <4-byte length>, and the last ten bytes for a v5 signature are 0x05 0xFF <8 byte length>. Therefore, any valid v4 signature of type 0xFF can be converted into a valid v3 signature (of different data). This can be mitigated by disallowing signatures of type 0xFF. For v5 signatures, the situation is worse: the fifth-from-last byte will nearly always be 0, which means that a v5 signature is ambiguous with a v3 signature of type 0. This means that any software that supports both v3 and v5 signatures will be insecure. There is no ambiguity between v4 and v5 signatures because the fifth-from-last hashed byte in a v5 signature cannot be 0xFF. This would correspond to an amount of hashed data that is so large it cannot fit in any signature packet.

To avoid all of these problems, I recommend changing v5 signatures so that the last 10 bytes of hashed data are <high 4 bytes of length> 0x05 0xFF <low 4 bytes of length>. This is clearly unambiguious with v4 signatures, and is also unambiguous with v3 signatures of type other than 0xFF. The alternative is to ban verification of v3 signatures entirely, but this is not a good choice; for one, I believe some RPM packages are still signed with them.