Potential IDPrism problem
Nathan D. Bowen
nbowen+yadis at andtonic.com
Thu Jun 30 13:14:53 PDT 2005
>It shouldn't need padding. You're XORing two 20-byte strings together
>and then encoding them.
Depending on the values of those two 20-byte strings, the XOR might
result in a value that *could* be represented in fewer than 20 bytes.
Whether or not it *is* represented with fewer than 20 bytes would be
dependent on the implementation. So some implementations might need to
pad the result of the XOR to get 20 bytes.
My perl's rusty, but from my understanding, Net::OpenID::Server is
another example of a server that will send 19 bytes if it XORs two
values that happen to begin with the same 8 bits.
However, it's not just a coincidence that the IDPrism server is where
this problem showed up. That installation is using the DH secret as the
MAC secret, so the proper value for enc_mac_key is 0.
I haven't seen any other consumer fail because it didn't receive 20
bytes in the enc_mac_key, but I made the change because I assume that
*every* consumer will be happy with 20 bytes.
I'm not sure the spec is clear on the correctness of sending fewer than
20 bytes, but from a standpoint of robustness I'd say that server
implementors would always want to send 20; consumer implementors would
always want to accept fewer.
More information about the yadis