>>>>> On Tue, 10 Feb 2015 16:48:08 -0500, David Mandelberg
>>>>> <[email protected]> said:
DM> All, while coming up with the example below, I realized another
DM> issue. The structure in 4.1 doesn't include an Address Family
DM> Identifier. Unless I missed something, this means that a
DM> signature for 1.2.0.0/16 would be exactly the same as a
DM> signature for 102::/16. This would be a much more practical
DM> attack than the one I originally though of.
DM> Michael, response to your comment is below.
DM> 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.
DM> You're right about digest algorithms being highly sensitive to
DM> changes in the input, but the issue I described is when the two
DM> inputs are equal, not just similar. For example, if a router
DM> signed the below values in the structure from 4.2:
DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708
DM> pCount = 0x01 Flags = 0x00 Most Recent Sig Field =
DM> 0x00700102030405060708090a0b0c0d0e (See Sriram's email for why
DM> this would never actually happen with the current algorithm
DM> suite's signature length.)
Ah, I see. Thanks for the explanation. I was not understanding the
attack vector but I get how it would work now (and good to know the
input won't match with the current algorithm).
-Mike
DM> Then the router signed the digest of the bytes
DM> 0x0102030405060708010000700102030405060708090a0b0c0d0e. However,
DM> these exact same bytes could appear to have come from the
DM> structure in 4.1 with these values:
DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708
DM> pCount = 0x01 Flags = 0x00 Algorithm Suite Id = 0x00 NLRI Length
DM> = 0x70 (112 bits = 14 bytes) NLRI Prefix =
DM> 0x0102030405060708090a0b0c0d0e
DM> Note that the first 16 bits of 4.2's Most Recent Sig Field can't
DM> be any values. The first 8 have to match the Algorithm Suite ID
DM> (1 possible value). The next 8 have to be a valid number of bits
DM> for the number of bytes in the prefix (8 possible values). This
DM> means that there's only a 2^-13 chance that a single random Most
DM> Recent Sig Field of the appropriate length could be
DM> reinterpreted successfully. However, with more than 2^13
DM> signatures floating around the Internet, that's not good odds.
DM> -- David Eric Mandelberg / dseomn http://david.mandelberg.org/
DM> _______________________________________________ sidr mailing
DM> list [email protected] https://www.ietf.org/mailman/listinfo/sidr
--
Michael Baer
[email protected]
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
