You know PFS while a good idea, and IMNSO all non-PFS ciphersuites should be
deprecated etc, PFS just ensures the communicating parties delete the key
negotiation emphemeral private keys after use.
Which does nothing intrinsic to prevent massive computation powered 1024
discrete log on stored PFS traffic, other than to the limited extent of
creating a fresh public key to attack on each session.
A secondary point if you are concerned about after-the-fact computational
power overtaking your stored ciphertext (PFS or not) is to avoid using
shared public crypto parameters for discrete log based cryptosystems.
Shared public parameters are also bad because there can be some reusable
precomputation or shared parameter specific optimized hardware. The flip
side is the parameter generation for the EC DL cryptosystems is so complex
that it will probably be safer for most purposes to use a standardized
parameter set, than to generate your own, if your library even supports it.
Adam
On Fri, Mar 23, 2012 at 08:42:29AM -0400, d...@geer.org wrote:
jd...@lsuhsc.edu writes, in part:
> Even if the intercepted communication is AES encrypted and unbroken
> today, all that stored data will be cracked some day. Then it too
> can be data-mined.
What percentage of acquirable/storable traffic do you
suppose actually exhibits perfect forward secrecy?
--dan
...those who control the past control the future.
-- George Orwell
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
