Hi David,
On 2/10/15, 1:48 PM, "David Mandelberg" <[email protected]> wrote: >All, while coming up with the example below, I realized another issue. >The structure in 4.1 doesn't include an Address Family Identifier. >Unless I missed something, this means that a signature for 1.2.0.0/16 >would be exactly the same as a signature for 102::/16. This would be a >much more practical attack than the one I originally though of. But, isn¹t this issue covered by origin-AS validation? Regards, Keyur > >Michael, response to your comment is below. > >On 02/10/2015 12:09 PM, Michael Baer wrote: >> I don't believe this is a problem. The signature is calculated by >> creating a digest of the data and then creating a signature from that >> digest. I'm definitely not a cryptography expert, but my understanding >> of digest functions generally is that with even slightly differing >> input, the resulting set of bits should be completely different. >> Assuming the digest function chosen is not flawed, there shouldn't be a >> set of bits from the digest of 4.1 that could be used to successfully >> replace the digest of 4.2, except by chance. > >You're right about digest algorithms being highly sensitive to changes >in the input, but the issue I described is when the two inputs are >equal, not just similar. For example, if a router signed the below >values in the structure from 4.2: > >Target AS Number = 0x01020304 >Origin AS Number = 0x05060708 >pCount = 0x01 >Flags = 0x00 >Most Recent Sig Field = 0x00700102030405060708090a0b0c0d0e (See Sriram's >email for why this would never actually happen with the current >algorithm suite's signature length.) > >Then the router signed the digest of the bytes >0x0102030405060708010000700102030405060708090a0b0c0d0e. However, these >exact same bytes could appear to have come from the structure in 4.1 >with these values: > >Target AS Number = 0x01020304 >Origin AS Number = 0x05060708 >pCount = 0x01 >Flags = 0x00 >Algorithm Suite Id = 0x00 >NLRI Length = 0x70 (112 bits = 14 bytes) >NLRI Prefix = 0x0102030405060708090a0b0c0d0e > >Note that the first 16 bits of 4.2's Most Recent Sig Field can't be any >values. The first 8 have to match the Algorithm Suite ID (1 possible >value). The next 8 have to be a valid number of bits for the number of >bytes in the prefix (8 possible values). This means that there's only a >2^-13 chance that a single random Most Recent Sig Field of the >appropriate length could be reinterpreted successfully. However, with >more than 2^13 signatures floating around the Internet, that's not good >odds. > >-- >David Eric Mandelberg / dseomn >http://david.mandelberg.org/ > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
