 |
 |
I am opening this issue here because the discussion on the dev group concerning this is stalled.
From the point of view of the current dCache implementation, there seems to be a length mismatch between the actual signature sent and the hashing of the message, even though the hashed part corresponds.
If I understand correctly, when the message header + body is hashed using SHA256, the result should be a 32 byte sequence.
The signature that the dCache server is receiving from the 4.10.0 client, however, is 48 bytes long. Moreover, the extra 16 bytes consistently decode to:
0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10 0x10
which seems to serve no purpose.
To illustrate further, here is a TRACE level logging excerpt from the dCache server:
The first byte dump shows the encrypted SigVer signature hash. The prepended IV vector (red rectangle) is extracted, and decryption proceeds as normal, producing the decrypted version which consists of the green rectangle (hash proper), plus the blue 16-byte sequence above.
Notice then that the actual message (in this case, a kXR_stat request), when hashed according to the protocol specification –– that is, using the received random 64-bit sequence number + header + payload –– produces exactly the byte sequence in the green rectangle.
However, the comparison fails because the hash is 32 bytes long, and missing the 16 byte nonce.
If I change the code to ignore any bytes in the SigVer signature after the 32nd, then the comparison works.
It is not clear to me why those extra 16 bytes are there, and what I should do about them.
Nor is it clear whether the symmetrical encryption part, which dCache would use to sign requests from its third-party client to send to the xrootd server, should be similarly expanded by 16 bytes. And why those bytes, before encryption, should be uniformly 0x10 (i.e., decimal 16).
Thank you for looking at this and helping me clarify.
Al
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1