|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Wed, 23 Apr 2008 12:18:03 -0400 From: Jack Lloyd <lloyd@randombit.net> To: Cryptography <cryptography@metzdowd.com> Mail-Followup-To: Cryptography <cryptography@metzdowd.com> In-Reply-To: <871w4w4vas.fsf@snark.cb.piermont.com> On Wed, Apr 23, 2008 at 08:20:27AM -0400, Perry E. Metzger wrote: > There are a variety of issues. Smart cards have limited capacity. Many > key agreement protocols yield only limited amounts of key > material. I'll leave it to others to describe why a rational engineer > might use fewer key bits, but suffice it to say, there are quite > rational reasons. I'll agree that if you have no tradeoffs, you might > as well use longer keys, but if you really have no tradeoffs, you > would prefer to use a one time pad, too. All real engineering is about > tradeoffs. I think one point worth making is that we probably don't really know how to make a cipher that is secure to, say, 2^512 operations (or 2^1024 or 2^4096 or whatever). For instance if you took Serpent or AES or Twofish and modified it to support 512-bit keys, I don't believe the resulting cipher would actually be secure to 2^512 operations... to guess completely at random, I'd say they would be more like 2^300 or so. (Have any block ciphers with 256-bit block/512-bit key been proposed/studied? I have not been following FSE and similar conferences of late) Making a cipher that uses an N bit key but is only secure to 2^M operations with M<N is, firstly, considered broken in many circles, as well as being inefficient (why generate/transmit/store 512 bit keys when it only provides the security of a ~300 bit (or whatever) key used with a perfect algorithm aka ideal cipher - why not use the better cipher and save the bits). -Jack --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |