Well yes the length of the DH KA prime in the DRDA specs is 256 bits - I talked to the Open Group some months ago to try and propose an addendum to increase the length of the modulus and allow a 512-bit (strong) prime but I was suggested to use some other and defined security mechanism as part of the DRDA specs (like encrypted connections ;-)), but I worked on strong password substitute (USRSSBPWD) which of course is quite different than 'EUSRIDPWD' scheme but at the end both do NOT send a clear password across the wire...USRSSBPWD sends the userid in clear whereas EUSRIDPWD does not.
I personally think a prime of 256-bit is weak (512 is really the minimum recommended with many applications using even 1024-bit primes during DH KA exchanges for governement applications...) for DH KA but of course the shared-key generation operation is a costly one, hence a prime of 512-bit would be ok. With USRSSBPWD, the password is not sent encrypted but a strong-hashed substitute one...If the DH KA prime imposed by DRDA would just not be 256 but allow something larger, then I believe 'EUSRIDPWD' mechanism would be the preferred mechanism of choice - this is just my humble opinion of course... For information about the DRDA prime restriction of 32 bytes and the defined value in the specs, have a look at the 'Generating the Shared Private Key' p. 281 of DRDA, Version 3, Volume 3: Distributed Data Management (DDM) Architecture... Hope this helps a bit, --francois Anyway, Sun JCE and some early version of the IBM JCE On 2/18/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: > > Current client driver supports encrypted userid/password (EUSRIDPWD) > > via the use of DH key-agreement protocol - however current Open Group > > DRDA specifications imposes small prime and base generator values > > (256 bits) that prevents other JCE's (apt from ibm jce) to be used > > as java cryptography providers. > > If it's not too much trouble, can you cite chapter and verse here? I find > myself a little surprised that DRDA actually *requires* a short key > length; I would have thought that it might default to a short length, but > would allow longer lengths to be used if the user desired. > > I hunted around a bit, and here's what I saw: > > EDTASECOVR, page 324 of V.3: > > The ENCALG parameter indicates the encryption algorithm to use. This > example assumes that the default DES encryption security algorithm > is specified. The ENCKEYLEN parameter indicates the encryption key > length to use. This example assumes that the default 56-bit encryption > is specified. > > ENCKEYLEN, page 332 of V.3: > > The Encryption Key Length (ENCKEYLEN) specifies the encryption key > length to be used with ENCALG to encrypt and decrypt the security > context information. ENCKEYLEN is used by the encryption security > mechanisms. > > Please educate me; I am a rank beginner on this crypto stuff. > > thanks, > > bryan > > > > >
