LWN: Comments on "Tarsnap advisory provides a few lessons"

Tarsnap advisory provides a few lessons

Darkmere — Sat, 22 Jan 2011 12:47:44 +0000

I'll concede to that, I just took the time to re-read the Open Source definition. Sorry for the error.

Tarsnap advisory provides a few lessons

jpnp — Sat, 22 Jan 2011 11:47:58 +0000

Please. Visible source is not Open source. It's certainly much better to have access to the source code of security components than not, but Open Source Software has a more explicit meaning.

Tarsnap advisory provides a few lessons

Darkmere — Fri, 21 Jan 2011 21:24:51 +0000

No, but it is (partially) open source. Not Free Software, but the Source is there.

Tarsnap advisory provides a few lessons

jeremiah — Fri, 21 Jan 2011 21:16:33 +0000

We do this for our clients, but it's an in house service. And the margins are Crazy! Definitely worth your or someone else's time. Or Tarsnap's as it were. It's a fun easy business model that doesn't require much effort if you roll it into software and products you already sell.

Tarsnap advisory provides a few lessons

dlang — Fri, 21 Jan 2011 19:14:03 +0000

just a suggestion, but when posting a link to your project, a link to the main page is better than a link to a hackfest contest.

and yes, I do think it would be good to have someone use your project to provide a similar service to tarsnap, due to the low barrier of entry, they may not make very much money on it, but competition is good.

I think the biggest reason that tarsnap got so many new sign-ups is the 'any publicity is good publicity' effect, most people had not heard of the option, in investigating what the fuss is about they see it's something that they could use.

Tarsnap advisory provides a few lessons

patrick_g — Fri, 21 Jan 2011 17:17:57 +0000

Tarsnap is not free software.

Tarsnap advisory provides a few lessons

nettings — Fri, 21 Jan 2011 12:37:46 +0000

Chapeau!

I wonder if the alleged increase in business after this exemplary disclosure will ring a bell with beancounters at other security-relavant enterprises :-D

Hey Jon, where was your prediction that 2011 would see the first security incident related PR triumph for open source? ;)

Tarsnap advisory provides a few lessons

zooko — Fri, 21 Jan 2011 07:22:03 +0000

The author of the software and owner of the company, Colin Percival, posted to twitter that he has had a sharp increase in new sign-ups since this news went out!

http://twitter.com/#!/cperciva/status/28233291609935872

@cperciva Colin Percival Tarsnap signups since I announced the CTR nonce missing-increment bug are 500% above normal. Crazy.

I think this is funny! But also it means something -- I'm not sure what.

I must say that as a contributor to Tahoe-LAFS -- an open source project that is vaguely competitive (but also, as is often the case, sort of not competitive) -- I'm a bit jealous. When we accidentally expose our users to security failures we don't get a flood of new users! Maybe our security advisories are not as well-written:

http://tahoe-lafs.org/hacktahoelafs/

:-)

Also our security failures have never been this bad yet. I have committed one or two defects this bad to our source code over the last few years, but in each case our automated tests or my brilliant coding partners caught it before we published it in a new release.

Hm. http://www.tarsnap.com/ says he charges $0.30/GB-month. That's roughly three times what Amazon Web Services is charging him. This really makes me wonder if I could go into business doing this. I could use Tahoe-LAFS, charge the same rates that tarsnap charges, and my marketing pitch could be "charges the same as tarsnap, uses the same backend, has similar or better security properties, and is all Free/Open Source Software". Yeah, that would be fun! And then tarsnap and Tahoe-LAFS would be actually competitive.

Oh well -- I have too many other things going on right now. But somebody should consider this! Those look like healthy margins to me.

By the way, I have been following Colin Percival's work and writings on tarsnap since long before this incident and I respect the way he does security engineering and the way he deals forthrightly with customers. And I greatly appreciate that his entire business model is focussed on the use case that nobody, not even tarsnap itself, gets access to the user's files. It is too bad about this defect that violated that intention, but the fact that he is selling that and (apparently) prospering from it is great!

Tarsnap advisory provides a few lessons

kruemelmo — Thu, 20 Jan 2011 17:12:18 +0000

the good example to deal with a security-related bug made us consider using this service.

Test suites for cryptography

epa — Thu, 20 Jan 2011 12:27:18 +0000

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.

Tarsnap advisory provides a few lessons

mjthayer — Thu, 20 Jan 2011 09:29:32 +0000

> 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.

Tarsnap advisory provides a few lessons

ion — Thu, 20 Jan 2011 07:02:54 +0000

Id also point out that having subtle side-effects within function call parameters might be something to be avoided. Had encr_aes->nonce++ been a separate expression it might have been less likely to be forgotten when refactoring.