[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A Photuris variant


More on you your comments.

 > Re DH overhead, we've discussed this at length before and I don't
 > think anything has changed. DH just isn't that expensive, especially
 > if you use an exponent length that's appropriate to your symmetric
 > cipher. Furthermore, you do NOT have to re-execute DH everytime you

Actually, you are one of the people that helped convincing me that
DH is NOT that INexpensive. You were mentioning not so encouraging
timings (several seconds), you talked about weak machines, and
more significantly, you proposed the use of precomputed (and
then replayable) signatures. The only reason to think about
such precomputation (with its attached security weaknesses) is
because of its performance benefits; if performance is not such big
deal why to suggest doing that?

BTW, using a short exponent is another compromise for performance.
To the best of my knowledge, your claims about the known security
of short exponents is correct (namely, the best known attack based on the
length k of the exponent is 2^{k/2}). However, this can eventually
change. Do you know of Wiener's result on RSA short exponents?
He shows a non-trivial atttack that works much better than the
above expression for exponents of length up to 1/4 of the modulus.
This attack does not seem to generalize to DH, but there was no
reason to believe on non-trivial weaknesses of short RSA exponents
before Wiener's work. Well, I am NOT trying to say that using
relatively short exponents must be prohibited. I am only trying to
point out that the cost of thiee operations is significant enough
to encourage people going to these shortcuts.

My proposal (which does not exclude the use of short
DH exponents) tries to give clear trade-offs of computation and
well-understood security. It is a reality that many people believe
they do not need DH everywhere, and even for me, a security-exigent,
it is reasonable that some scenarios do not require it.

 > establish a new session key. My current plan is to generate session
 > keys by MD5 hashing the DH secret, the SAID and the cookies. So after
 > a given host pair has done DH once, they can create as many new
 > uniquely-keyed SAIDs as they need for only one MD5 operation each. (Of
 > course, they'd always have the option of re-executing the DH exchange
 > at any time.)  Doesn't this satisfy your desire for a quick way to
 > rekey your weak symmetric ciphers?

This is an important issue. Whatever is your public-key based way
of sharing keys, a secure and efficient (MD5-like complexity) mechanism
for re-keying is required. There are several ways to do it.
I'd like to  hear exact details on how you propose to do it.
In the meantime, my preferred method is the one we propose in our
MKMP draft.

Discussions on this last issue can be carried independently of
discussions/decisions on the PK-based key management
(it can, and should, be independent)