Date: Thu, 3 Jun 1999 10:45:39 -0400 From: Adam Shostack <adam@homeport.org> To: Narvi <narvi@haldjas.folklore.ee> Cc: Laurence Berland <stuyman@confusion.net>, security@FreeBSD.ORG Subject: Re: Not freebsd related...yet Message-ID: <19990603104539.A25645@weathership.homeport.org> In-Reply-To: <Pine.BSF.3.96.990603160824.3570J-100000@haldjas.folklore.ee>; from Narvi on Thu, Jun 03, 1999 at 05:14:35PM %2B0300 References: <19990603085644.A24954@weathership.homeport.org> <Pine.BSF.3.96.990603160824.3570J-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 03, 1999 at 05:14:35PM +0300, Narvi wrote: | On Thu, 3 Jun 1999, Adam Shostack wrote: | > Actually, this will be 1. broken, and 2. uninteresting. I'd be happy | > to bet money if it wasn't a sucker bet. | > | > 1. Building a cipher with a large key is hard. See the first twofish | > paper, where Schneier et al, discuss the difficulty of building a key | > schedule to effectively use long keys. Getting 1024 BYTES of | > randomness is next to impossible, so your implementors will end up | > expanding a smaller pool of randomness into a large key. Given that | > this is unavoidable, you should anticipate it in your design, and have | > a key expansion phase. That you didn't know this is worrisome. | > | | Let's leave aside what he knows and what he doesn't. | | Using 1024 bytes of key is trivially easy if you are doing (large block) | block chipher. Say you have 1024 byte key and operate on 4096 byte blocks. | Subdivide the key into 64 16 byte subkeys and the key into 64 byte | subblocks. Now encode sublock n with subkey n using a conventional | chipher. The resulting enconging is stronger than the one used on the | subblocks. Then again, definately not enough to pay for the extreme | size... And the avalanche property? Your proposal is going to require a lot of rounds before each key bit has a chance to effect each bit of plaintext. | But I think he mixed up bytes and bits, and 1024bit keys aren't all that | bad. Yes, they are. Address my points about randomness and expansion, or don't. Few of the AES candidates have keys that can go longer than 256 bits. This is because the smart cryptographers who did the design were not comfortable with keys that long. | > 2. Building a system to use more resources than current systems, and | > expecting resource consumption to make it interesting is silly. | | I really don't think that he meant that. The only point he made was that he wanted to use really big keys. I suggest that this is not only a not useful goal, but it is likely to detract from the security of the system. | > If you want an interesting project, may I suggest trying to | > cryptanalyze one of the AES candidates? Its more interesting, will | > teach you a bunch, and may produce something useful. | > | > Sorry to flame, but this really isn't a good use of your time. | I gues he *HAS* to come up with something himself and then code it for his | CS final project. And crypto may very well also be set as the subset from | which he has to come up with something. If he needs to write code, there are a large number of useful projects that could be worked on; integrating crypto into a file system; integrating ssh-agent into an existing crypto file system; adding crypto to a protocol like icq or irc. I'd be fairly shocked to discover a professor who is assigning the creation of new systems as a senior project. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990603104539.A25645>