Michal, Gerri,


I am still scratching my head over this, so maybe you can help me out a bit.


The failure is triggered by the first message received after the GSI handshake is complete, obviously, when signing goes into effect.  It so happens that the the request id is:  3017, which is a kXR_stat request.

Now, the way the hash should be generated is to use

- a 64-bit random sequence number
- the message header
- the message body

As can be seen from the output I attached previously, the hash generation using the kXR_stat request on the dCache end does produce the same base64 string as the first 64 chars of the decrypted SigverRequest message (received).

So why do those extra bytes need to be there?  As far as the actual kXR_stat message is concerned, the IV vector used to encrypt the signature is irrelevant.  

Plus, it would seem that those 32 bytes are always decrypted to the same value: 10101010101010101010101010101010.

Thanks, Al

________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
From: Michal Kamil Simon <[log in to unmask]>
Sent: Tuesday, August 20, 2019 7:28:52 AM
To: Albert Rossi <[log in to unmask]>; xrootd-dev <[log in to unmask]>
Cc: Gerardo Ganis <[log in to unmask]>
Subject: RE: signed hash 4.9.1 4.10.0
 
Hi Albert,

The XrdSecProtocolgsi::Encrypt() method is only used by the
signing logic.

AFAIK the signature is longer by 32 bytes because in front of
the signature we append the initialization vector.

(I'm adding Gerri so he can correct me in case I'm wrong)

Cheers,
Michal
From: [log in to unmask] [[log in to unmask]] on behalf of Albert Rossi [[log in to unmask]]
Sent: 19 August 2019 19:05
To: Michal Kamil Simon; xrootd-dev
Subject: Re: signed hash 4.9.1 4.10.0

More precisely, you will observe that the signature sent with 4.10.0 is indeed longer by 32 bytes:




________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
From: Albert Rossi <[log in to unmask]>
Sent: Monday, August 19, 2019 11:57:52 AM
To: Michal Kamil Simon <[log in to unmask]>; xrootd-dev <[log in to unmask]>
Subject: Re: signed hash 4.9.1 4.10.0
 

P.S.,


the bug  you point to seems to be a general encryption one.  


But it does not seem to be affecting normal DH (if I turn off sigver in dCache I can use the 4.10 client).




________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
From: Albert Rossi <[log in to unmask]>
Sent: Monday, August 19, 2019 11:54:52 AM
To: Michal Kamil Simon <[log in to unmask]>; xrootd-dev <[log in to unmask]>
Subject: Re: signed hash 4.9.1 4.10.0
 

Hi Michal,


OK, I see that now there are extra 32 bytes included in the signature.


With 4.9.1, dCache sees something like this:


19 Aug 2019 11:46:20 [xrootd-net-0] [door:Xrootd0-fndcatemp1@xrootd0-fndcatemp1Domain:AAWQexRQ3DA] compareHashes

received a36c3fc283cd0ba703bf87a8606c8557fad83d0783f8c117781ad4ec8084238b

generated a36c3fc283cd0ba703bf87a8606c8557fad83d0783f8c117781ad4ec8084238b


With 4.10.0, instead, there is the 32-byte: 10101010101010101010101010101010


19 Aug 2019 11:46:31 [xrootd-net-1] [door:Xrootd0-fndcatemp1@xrootd0-fndcatemp1Domain:AAWQexT+7rA] compareHashes, different lengths:

received de7a8af3e690059f5550ede93ec3ede4723afd2a4fe2ce3656e3820e0d5d9c3e10101010101010101010101010101010

generated de7a8af3e690059f5550ede93ec3ede4723afd2a4fe2ce3656e3820e0d5d9c3e


Why is that now there?


The specification (http://xrootd.org/doc/dev49/XRdv400.htm#_Toc532936621)

4.26.1    Signing a request


still states that the hash + data sequence should be (for SHA-2 / SHA256): 


*    1. an unsigned 64-bit sequence number,
*    2. the request header, and
*    3. the request payload,
*  in that exact order.

How is this extra 32 bytes to be handled?


Thanks,


Al

________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023
From: Michal Kamil Simon <[log in to unmask]>
Sent: Friday, August 16, 2019 11:17:58 AM
To: Albert Rossi <[log in to unmask]>; xrootd-dev <[log in to unmask]>
Subject: RE: signed hash 4.9.1 4.10.0
 
Hi Albert,

There was a bug in calculating the size of signature that has been fixed
right before releasing 4.10.0:

Cheers,
Michal
From: [log in to unmask] [[log in to unmask]] on behalf of Albert Rossi [[log in to unmask]]
Sent: 16 August 2019 16:33
To: xrootd-dev
Subject: signed hash 4.9.1 4.10.0

Hello,


I am testing the 4.10 client against the current implementation of dCache, and have found the following (xrdcp491 and xrdcp410 are small bash wrappers that point to different xrootd installations and ensure the LD_LIBRARY_PATH is correct. 


[arossi@otfrid ~]$ xrdcp491 /etc/fstab root://fndcatemp1.fnal.gov:1094//pnfs/fs/usr/test/arossi/volatile/fstabwith491-test
[574B/574B][100%][==================================================][574B/s]  


[arossi@otfrid ~]$ xrdcp410 /etc/fstab root://fndcatemp1.fnal.gov:1094//pnfs/fs/usr/test/arossi/volatile/fstabwith410-test
[0B/0B][100%][==================================================][0B/s]  
Run: [ERROR] Server responded with an error: [4003] signed hash verification: received hash length does not match generated hash.



Has the signed hash implementation in the client changed between 4.9 and 4.10?


Thanks,  Al

________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W)
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023

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


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


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