On Jan 26, 2011, at 9:30 47PM, Jon Callas wrote:
>
> On Jan 26, 2011, at 1:56 PM, Samuel Neves wrote:
>
>> On 26-01-2011 19:36, Jon Callas wrote:
>>> Why are you leaning to Rabin-Williams for all the features that are also
>>> features of RSA? People don't break signatures because of hard problems,
>>> they break them because the software has bugs in it. You're discussing the
>>> resistance of the walls to a chainsaw, while leaving a bread tie on a hasp
>>> as the lock.
>>>
>>> Jon
>>
>> Well, why not? R-W signatures are as good as RSA, plus they have a)
>> tight security reduction b) can have up to 3x faster verification than
>> e=3 RSA.
>
> I will admit to yanking a chain a bit, but there are reasons for it. First,
> as we've seen time and time again, crypto doesn't get broken, software does.
> It's far more important to have a tested, stable, and evaluated software base
> than any algorithm vs. algorithm debate. Unless you're confident the chance
> of your software has a horrid bug is 2^-64 or less, algorithm debates are
> debating which link in the chain is strongest, when we should be debating
> which is weakest.
>
> Second, crypto doesn't exist in a vacuum, it is a part of some system that is
> supposed to solve a problem. Without that context, the debate is like arguing
> what the best tool is for a wood shop. It's impossible to really have a
> discussion without knowing what we're going to make in the shop.
>
> That's why I said RSA, which is kinda like saying, "circular saw --
> definitely a circular saw."
>
> Absent a problem analysis, you should always stick to the standard algorithm
> set. You need to be prepared to fill in the sentence: "I used X instead of
> RSA or DSA because the problem I'm addressing has parameter A, B, and C that
> make them unsuitable because of P, Q, and R."
>
> The usual gang of algorithms are preferred for a number of reasons that
> include:
>
> * Over the last twenty years, we've learned a lot about them in practice. The
> systems that use them are relatively easy to design, evaluate, and build. We
> know about subtle non-crypto algorithm errors (e.g. padding oracles), and
> common implementation errors.
>
> * Even more importantly, they're easy to maintain. You want to work on some
> project after that, right? Then you don't want to build it out of something
> that you can't easily hire people to maintain.
>
> * If you want your system to be used by a regulated or quasi-regulated
> industry (banking, finance, retail, healthcare, government, manufacturing,
> etc.) then they're going to look at you funny if you stray from the usual
> algorithm set.
>
> * We've been telling the world for years that they should avoid home-grown
> crypto, and that they should stick to well-trodden ground because it's
> dangerous out there. And they listened to us! But that means that when you
> talk about the virtues of Rabin-Miller, they're going to hear, "blah, blah,
> snake oil, blah," unless you have a really good story. The presumption today
> is that if you're not using the standard algorithms, you don't know what
> you're doing.
>
> So yes, indeed, Rabin-Miller is a perfectly fine algorithm. I'm quite fond of
> it and I've argued in the past that it's *better* mathematically than RSA.
> But from a software, systems, and cultural perspective, it's not a good
> choice. Our discipline has matured to the degree that math is no longer what
> drives things.
Thank you.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
