[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Diffie-Hellman (note by Hugo)
Hilarie says:
> > James P Hughes says:
> > > 3. Over the lifetime of a standard (10 years or so), something that is
> > > marginal because it is processor intensive now, and will be not at all too
> > > expensive in the future.
> > I could not agree more. What seems slow now will seem trivial in five
> > years.
>
> One might note a corollary that what seems secure now will probably
> seem less secure in 5 years. There's probably a crypto aphorism about
> computational cost: no pain, no security. Encrypt 'til it hurts and always
> leave room for larger numbers.
I agree with all of these comments, i.e.: what seems slow now may not seem
slow in 5 or 10 years, and also that this similarly applies for security -
to a large extent simply because of the availability of better HW also to
the crackers (after all, with all cryptoanalysis of DES, the best attacks
known are still basically brute force, only they now are quite realistic).
However we should beware of over simplifying. In particular, we should keep in
mind:
1. A cryptosystem which is more computationally intensive is not necessarily
more secure. The classical example is the fact that in order to achieve
security
with known public key cryptosystems, one should work much harder than what
is considered enough with symmetric cryptosystems. This does not mean public
key is inferior, since public key buys you features which are impossible with
symmetric crypto. It only means the two mechanisms should be combined as
indeed we plan to do (by using symmetric techniques in IPSP, and in our
proposal for using them also for the more frequent key updates in MKMP
together with infrequent use of more expensive public key or DH operations).
2. While the security of cryptosystems is not proven and indeed changes with
time, this should not hold for the protocol. It is possible to design protocols
with modularity which would allow them to be used (with different
cryptosystems)
forever. For this purpose it is desirable to be able to have a reduction
proof for the protocol as we know to do at least for simple protocols e.g.
the short-lived module of MKMP.
3. What does one do to repair an implementation if cryptoanalysis of the
cryptosystem used becomes easier? The obvious solution is to replace the
cryptosystem, but this may be difficult and take long. Another potential
remedy is to refresh keys more frequently. This is one of the motivations
for having a highly efficient and simple mechanisms for short-lived key
refresh as we propose in MKMP.
Best, Amir Herzberg
References: