User: Password:
|
|
Subscribe / Log in / New account

Tarsnap advisory provides a few lessons

Tarsnap advisory provides a few lessons

Posted Jan 20, 2011 9:29 UTC (Thu) by michaeljt (subscriber, #39183)
Parent article: Tarsnap advisory provides a few lessons

> In the comments on the advisory, Percival said that Tarsnap does not have a test suite of that sort, and pointed out that it is difficult to create one for cryptographic software, but "I should probably find some way of automatically testing and/or assert()ing for nonce-reuse bugs though".

At least theoretically, a regression test that catches (some) refactoring errors seems feasible to me. You decide on a set of test workloads to run and make sure that the result (in this case the encrypted output) is identical before and after. After any non-refactoring change though you will need to update your expected test results.


(Log in to post comments)

Test suites for cryptography

Posted Jan 20, 2011 12:27 UTC (Thu) by epa (subscriber, #39769) [Link]

You're right, a simple before-and-after test would have caught it.

A parallel approach would be to write a dummy cryptography library which essentially spews out the inputs unchanged - so the encrypt() function, rather than returning encrypted data, gives a string saying 'key = xxx, plaintext = yyy, parameters = zzz'. The dummy random number generator will just return 1, 2, 3 etc. You can then inspect the output by hand, or by an automated tool, to check for logic errors such as the same key being used twice when it should not be. This test would only be as good as the person writing the automated checker, but it might provide another chance to catch certain bugs.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds