|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com X-Original-To: cryptography@metzdowd.com Date: Thu, 16 Dec 2004 10:09:49 +0000 From: Ben Laurie <ben@algroup.co.uk> To: "C. Scott Ananian" <cscott@cscott.net> Cc: Tim Dierks <tim@dierks.org>, Bill Frantz <frantz@pwpconsult.com>, Cryptography <cryptography@metzdowd.com> In-Reply-To: <Pine.LNX.4.61.0412151302130.17599@cag.csail.mit.edu> C. Scott Ananian wrote: > On Wed, 15 Dec 2004, Tim Dierks wrote: > >> Here's an example, although I think it's a stupid one, and agree with > > [...] > >> I send you a binary (say, a library for doing AES encryption) which >> you test exhaustively using black-box testing. > > > The black-box testing would obviously be the mistake. How can you tell > that the library doesn't start sending plain-text for messages which > start with a particular magic bytes, or some other evilness? You can't > hope to test *all* messages. The word 'exhaustively' is where your > example goes wrong. > > I'll play Ben's part and claim that if you can provide a library which > will *only* be checked using black-box testing, it's much easier to skip > the whole MD5 aspect and have it use a covert channel (leak key bits in > padding or some such) or transmit plain-text after the first 100M of > data encrypted or some such. There are lots of easy ways to get your > maliciousness past a black-box test. The use of MD5 (a relatively > *hard* way to be malicious) doesn't appreciably change the threat. Exactly so, thankyou. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- 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 |