Print

Print


forgot to give the link between bucket and DH. DH parameters are transmitting in one of the bucket, with type "kXRS_puk". I guess Brian is proposing to send both unpadded and padded DH pars, in two different bucket (with different type).

--
Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)
 

On 12/7/18, 2:36 PM, "[log in to unmask] on behalf of Yang, Wei" <[log in to unmask] on behalf of [log in to unmask]> wrote:

    Gerri is probably the right person to answer.  From what we see, bucket is a unit for info exchange used in Xrootd GSI security. Many  (unique) types of buckets can be added to a buffer (of type XrdSutBuffer), the buffer is then serialized and sent to the other end of the wire. The other end can retrieve those buckets based on their type. 
    
    This brings up another question: is dcache implementation using similar data structure? If so, some of the documents we will produce can stay at bucket/buffer level. Otherwise, we need to find out how deep we need to dive to find a common denominator between the C++ and Java implementations.
    
    --
    Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)
     
    
    On 12/7/18, 1:51 PM, "[log in to unmask] on behalf of Dmitry O Litvintsev" <[log in to unmask] on behalf of [log in to unmask]> wrote:
    
        Brian,
        
        How would it work with a "new bucket"? I am just not connecting the issue of padding
        and DHE signatures Andy is adding. Please expand a bit.
        
        Dmitry
        
        ________________________________________
        From: Brian Bockelman <[log in to unmask]>
        Sent: Friday, December 7, 2018 3:09:37 PM
        To: Dmitry O Litvintsev
        Cc: [log in to unmask]
        Subject: Re: question about using DH_compute_key calls in XrdCryptosslCipher
        
        Hi Dmitry,
        
        It's a timely email - about 1 hour ago, Andy merged a PR that was tinkering with the contents of this bucket (adding a signature to the DHE to mitigate a MiTM).
        
        Unfortunately, OpenSSL 1.0.2h is fairly new compared to the minimum version Xrootd must support (RHEL6's 1.0.1e).
        
        What if we introduce a new bucket type for this and the extension that Andy just merged?  How accepting is the dCache code of new bucket types?
        
        Brian
        
        > On Dec 7, 2018, at 2:58 PM, Dmitry O Litvintsev <[log in to unmask]> wrote:
        >
        > Hi,
        >
        > dCache uses bouncycastle (BC) java crypto library.
        > When we updated to BC version 1.5 we started to see occasional
        > (about 1 in 200) exceptions:
        >
        > javax.crypto.BadPaddingException: pad block corrupted
        >
        > when using xrdcp with gsi security against dCache xrootd server.
        > (secure handshake fails).
        >
        > We have tracked down the problem to the padding the secret with leading
        > zeroes when converting number to to byte array that has been introduced
        > in BC based on RFC 2631 (2.1.2) specification and the use of  DH_compute_key in  XrdCryptosslCipher in xrdcp client.
        >
        > We replaced  DH_compute_key with DH_compute_key_padded calls and do not
        > observe the issue anymore.
        >
        > DH_compute_key_padded appears in openssl in version 1.0.2h  [25 Aug 2016]:
        >
        > """
        >  *) New function DH_compute_key_padded() to compute a DH key and pad with
        >     leading zeroes if needed: this complies with SP800-56A et al.
        >     [Steve Henson]
        >
        > """
        >
        > Are there principal objections/considerations of not using DH_compute_key_padded in XrdCryptosslCipher? (beyond compatibility issue - obviously a client implemented w/ DH_compute_key_padded would not work against server implemented  w/ DH_compute_key).
        >
        > If turns out there are no objections we could think of some backward-compatible way
        > of introducing these functions.
        >
        > Thank you,
        > Dmitry
        >
        > ########################################################################
        > Use REPLY-ALL to reply to list
        >
        > To unsubscribe from the XROOTD-DEV list, click the following link:
        > https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=7PHi3TDlwkvpc07MjENbOxVFl0u_sEurf250JnUFWCU&m=-HqMYppV4NUNFG0CTrXkFgpdzNNtVAAuFc6ivwtlwcI&s=jvnjAL9G37ZCLjoId5YQFcKcN72gTSW1iQEo5qIDN_8&e=
        
        ########################################################################
        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