db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: [jira] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.
Date Mon, 20 Feb 2006 01:07:43 GMT
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 <bpendleton@amberpoint.com> 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
>
>
>
>
>

Mime
View raw message