Re: ssl-enum-ciphers

[Daniel Miller <bonsaiviking () gmail com>]

Just to clarify, since this is a complicated issue:

The subject of bit-strength of different encryption and key exchange
methods is a subject of some debate. Because we try to appeal to standards,
we have chosen NIST Special Pub 800-57, part 1 revision 3, to be our
standard for comparing the bit-strength of elliptic curve (EC),
Diffie-Hellman (DH), RSA, and DSA, which are the most common (only?) key
exchange methods supported by TLS. The function which converts these values
to RSA-equivalent bit strengths is tls.rsa_equiv, which is simple enough to
reproduce here:

-- Get the strength-equivalent RSA key size
--
-- Based on NIST SP800-57 part 1 rev 3
-- @param ktype Key type ("dh", "ec", "rsa", "dsa")
-- @param bits Size of key in bits
-- @return Size in bits of RSA key with equivalent strength
function rsa_equiv (ktype, bits)
  if ktype == "rsa" or ktype == "dsa" then
    return bits
  elseif ktype == "ec" or ktype == "dh" then
    if bits < 160 then
      return 512 -- Possibly down to 0, but details not published
    elseif bits < 224 then
      return 1024
    elseif bits < 256 then
      return 2048
    elseif bits < 384 then
      return 3072
    elseif bits < 512 then
      return 7680
    else -- 512+
      return 15360
    end
  end
  return nil
end

Qualys's SSL Labs, which is pretty much the industry standard for
evaluating TLS configuration, chooses to display DH parameter strength in
terms of the RSA-equivalent key strength, so perhaps we should consider
changing this display. If anyone has examples of common software that
refers to the DH parameter strength in one or the other format, that could
contribute to changing or keeping our format.

Dan

On Tue, Jun 2, 2015 at 3:48 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> Dave,
>
> The length is the size in bits of the "p" portion of the DH parameters.
> For calculation purposes, it is converted to a RSA-equivalent key strength
> with the tls.rsa_equiv function [1].
>
> Dan
>
> [1] https://nmap.org/nsedoc/lib/tls.html#rsa_equiv
>
> On Tue, Jun 2, 2015 at 10:09 AM, Dave Smith <agentsmith77 () gmail com>
> wrote:
>
> > Hi All,
> >
> > https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html
> >
> > Even the documentation page shows a sample output with a key exchange of
> > "dh 256", i've seen this repeatedly coming up on a number of specific DHE
> > ciphers which are not ECDHE (explaining such a low size).
> >
> > TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 128)
> >
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 128)
> >
> > TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 128)
> >
> > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 128)
> >
> > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 128)
> >
> > TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 128)
> >
> >
> > I tried to find a rational explanation for the difference between a RSA
> > Kex and DH in the output , but didn't find it.
> >
> >
> > Could someone confirm if this is expected behaviour, and the brief
> > reason, or if it's misinterpreted by the script.
> >
> >
> > This was run on w2008 r2, with SVN 34457
> >
> >
> > thanks, Dave.
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/