[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
speaking of keys
Since we've been discussing the details of key derivation, the amount
of entropy we get from a 1204 bit DH exchange, and how that aligns
nicely with the 160-bit hash output from SHA-1, I want to raise a
related issue.
Consistent with our efforts to simplify IPsec in general, I suggest
that we mandate support for just one DH group (of 1024-bit size) and
require that products provide a management interface to allow
users/administrators to specify other groups as needed.
Althouhg I am not a cryptographer, it seems that the 160-bits we get
from a 1024-bit DH exchange is reasonable for use with 128-bit AES.
I believe that NIST suggests that 1024-it DH should be good until at
least 2015, although I forget what parameters they use in this
analysis.
Yes, I know we generate at least 2 and more often 4 keys from each DH
exchange (one each for encryption and integrity in each direction),
so the 128-bit key size and 160-bit entropy measures are not so
easily comparable.
I also worry that if we insist that all IPsec (IKE) implementations
support 1536-bit DH, that too many folks will decide to select that
option, under the "bigger is better" theme. However, the added
performance hit for 1536-bit DH is significant and might have the
unintended effect of causing folks to decide that the IPsec
performance hits is too big and thus choose not to employ IPsec at
all.
If we mandate support for locally selected DH parameters, then we do
permit more sophisticated user communities to select bigger groups,
with different parameters, if they really need to. I have received
feedback from some DoD clients that they want to use IPsec for
protecting unclassified data, but feel the need to use groups
selected by their crypto advisors (it's a union thing, I guess). it
seem that many IKE implementations do not provide a facility for
configuring other groups, and this poses problems for these folks.
Hence my suggestion to adopt just one MUST group, at the 1024-bit
size, but also mandate support for a management interface that allows
user communities to support "custom" groups. We could impose some
requirements on the max size groups that MUSt be supported via the
management interface (to ensure interoperability), without specifying
these other, bigger groups.
What do people think about this suggestion?
Steve