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