 |
 |
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