At 11:11 AM -0800 3/16/06, Michael Thomas wrote:
Which leads us back to the original question, I guess. I'm fairly
certain that nobody's going to spend any MIPS-years to factor
mtcc.com's public key.
... thousands of MIPS-years for a 512-bit key ...
They might consider it for something more
tempting like, oh say, Bigbank.com. Or they might try pharming
instead which is probably an easier tactic.
Right. Larger targets have both much more access to CPU power (and
therefore should use larger keys) but are also easier targets for
social attacks.
Signers SHOULD NOT use keys less that 1024 bits, receivers MUST
accept keys less that 1024 but MAY consider weaker keys as more
suspicious.
We have a huge problem with SHOULDs and MUSTs in this document: some
of them are for good security practices, others are for
interoperability. I'll bring more of these up later, but we might as
well start getting them right now where we can.
Alternate proposal: Because shorter keys may be able to be
compromised with off-line computational attacks, signers SHOULD NOT
use long-lived keys whose length is less that 1024 bits. Receivers
MUST be able to validate signatures with shorter keys, but may have
security policies that are linked to the length of the signing key.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html