[Cryptography] The GOTO Squirrel! [was GOTO Considered Harmful]

[ianG]

On 3/03/2014 15:18 pm, Theodore Ts'o wrote:
> On Mon, Mar 03, 2014 at 11:00:36AM +0000, ianG wrote:
>>
>> Second, it's a huge gap between knowing what to do, and doing it.
> 
> Those who can't do, teach.  :-)


And for those that can't teach, there's always the army :)


>> As to the yaddayadda about it being open source and everyone's welcome
>> to give it a go, no, sorry, might be the geek fantasy but it isn't the
>> reality.  Firstly, the open code is closed.  You can't just wander in
>> and fix it, they've got repos, barriers, code reviews, reputation, etc
>> to get through.  It's about as likely as me sending a dev/random fix in
>> to linus and expecting it to be slotted in.
> 
> If open source maintainers accepted every single patch that the
> senders were convinced were great ideas, I assure the code would be
> far buggier, and far less secure.  Trust me, I've seen the bright
> ideas and (to their minds) brilliant patches people send; the vast
> majority of them are terrible, and the one of the big reasons why
> Linux's random driver and ext4 code is better is because I reject (or
> ignore) the vast majority of crappy patches.


Yup, that's the reality.  So we're in loud agreement, that very open
source is part of projects that are very closed if anyone actually has
the temerity to discuss change.

Of course, *in principle* a patch could be accepted, but the reality not
the marketing is ... pigs fly faster;  it takes quite some time before
the average developer can earn his wings and can get up there and soar.


> But hey, if you can convince everyone else to follow your rewrite of a
> project, then it is open.  The problem is that most people aren't
> willing to trust random people who claim that they can improve code,
> or worse, they aren't willing to stand behind the code base, and send
> "drive by patches" and aren't willing maintain the code over the long
> term.  So the fact that most attempted code forks never gain traction
> is a not surprising --- and, and I claim, it's a good thing.


Yup, it's open like American democracy is open to another party.  Repeat
& rinse, civic classes at 3pm.

What probably is going on here is that the open source magic is blinding
insiders to the humdrum of basic economics.  Customers have mass, and
that mass can be gripped.  And closed off ... just like the old monopoly
days of old.

I'm not saying this is a bad thing, just that it's a thing.


>> Thanks but no thanks.  Recall an influential letter to ACM?  To be
>> frank, I'm not that keen to go back to the dregs of the literature of
>> the 1970s or 1980s when this work was likely done, in droves.  
> 
> And Peter Gutman's magic 30 pass secure HDD rewrite is still
> applicable today.  Seriously, the work done in the 1970's and 1980's
> is not necessarily valid for today's coding styles.  More importantly,
> it's not enough to do work just saying that <FOO> is bad.  All coding
> techniques have downsides.  This is why I said that the only way that
> you're not doing speculation or argument by assertion is to take a
> look at the number of bugs (security and otherwise) with alternate
> techniques, since it may be that an alternate technique avoids one
> class of bugs, but ends up opening the code to other classes of bugs.


As I mentioned, it is possible to write good security code in assembler,
but ... few do.

Why not?  There is another test that cuts through the theoretical /
academic / scientific method / evidence-or-death rhetoric, and that's
the market test.  When the market has moved on, it has spoken.


> It certainly wouldn't be the first time that conventional wisdom on
> things like "Microkernels is the only way to write Operating Systems"
> would turn out to be disastrously, terribly, wrong.  Sometimes when
> academic theorizing runs into the concrete wall of actual pratice,
> theory doesn't necessarily survive the impact with actual engineering
> reality terribly well.


Oh indeed.  But, one stood the test of time, the other didn't :)


>> Now we are left with:  why hasn't this been done?  I've indicated some
>> reasons above, another reasons is shear inertia.  A fourth reason is
>> hubris, 99% of the people involved think that they are doing a good job
>> (and they might be right) and therefore criticism is wrong and should be
>> dismissed out of hand (right or wrong, no change needed here...).
>>
>> If there is going to be any rewrite of this, it actually needs to start
>> by first getting the consensus moving that OpenSSL in particular and SSL
>> in general is utter crap.
> 
> Nope, it just requires someone to start writing code, and
> demonstrating to others that their code base is better.  Not just in
> theory, but in actual fact.  The IETF mantra of "rough consensus and
> running code" is really important here.  Especially the last bit of
> "running code".


That would be somewhere between a religious myth and unfounded fantasy.
 There is no way possible that some one person can write an SSL
replacement and get anywhere with PKIX, TLS, browsers, vendors, CAs,
government interested parties, standards orgs.  If you think that,
please send me all your bitcoin, I've got a bridge to sell you.

I know that the open source community has their mantra, but please....,
every religion has its blind points.  The IETF is not a place for open
source, it's the place for huge corps to duke it out, without killing
each other.  It's the Internet's answer to universal war.  For that
benefit, we thank it.  But open?  No, do not be fooled by the brochure.
 It's open if you're a household name, otherwise you're roadkill.


> So this is the big difference the two links you pointed out.  Your
> second one:
> 
>> https://www.mail-archive.com/cryptography@metzdowd.com/msg12958.html
> 
> Was basically saying, Someone Else should do something!


Nice knock down, but you missed the point.  The real point (again) is
that the plausible way to replace it is a movement, not an individual.


>> Brave steps:  here's a relative newcomer to the scene:
>> https://en.wikipedia.org/wiki/QUIC
> 
> And this is running code (both client and server), released under open
> source, and there are even servers on the web which are usign this new
> protocol.
> 
> See the difference?


Indeed.  See why my code isn't presented to the IETF?  Because I am one
person, or one business, and that's a non-starter.

See why google is giving it a go?  Because they are google, and they are
about the only ones who have a shot at this.  They are the only group,
bar none, that can make this happen.

Nobody else.  That's a prediction, by the way, and it's not that
reliable, as I'm not sure they can do it, but I hope they try.

Oh, except that part about "nobody else."  That you can take to the bank.


>>> Testing is like security.  You can't just sprinkle the magic testing
>>> pixie dust after you are done implementing, just as you can't (at
>>> least not practically) try to add security after the fact, if it
>>> wasn't designed in from the beginning.  (Or if you can, it requires
>>> infinite budgets....)
>>
>> Yup.  However, the fact that this is a difficult task needs to be
>> separated from the fact that they are running with a code base that
>> makes their job and our lives harder, and they have no strategy for
>> improvement.
> 
> "You can't change people; you can only change yourself".


So if I change myself, does this mean that CABForum will accept my
proposal to fix SSL?  No, I didn't think so, because the only 'changed
self' they will accept is in their own image.

Back to facts.  Back to earth.

> What's *your* strategy for making *your* life easier?  And if it so
> happens that your strategy can also make the rest of our lives easier,
> and you are willing to contribute some effort to make that happen,
> even better.


My strategy ... as you asked:  I'm building it and deploying it in
developing-world financial scenarios where mainstream institutions
cannot reach.  I'm doing it outside the mainstream western scenario
because of incumbrance and other issues.  Think bitcoin meets Grameen,
but without the imbalance, without the western mindset and definitely
without the helium.

As you're a technologist, I'll describe the tech:

Packets over UDP encrypted with AES/SHA1/HMAC (called SDP1) negotiated
over a request-response model with RSA signing (called SOX).  Once
secure UDP/SDP1 context set up, requests include monetary transactions,
identity info, files, chat and admin.  Values range across the spectrum
with gold, dollars, euros, shares, etc.  Although its tech genesis was
in small fast reliable financial transactions, as of a few months ago,
my intern coded up a large-packets-over-UDP in a month (yeah, that's all
it took, 1 intern-month) so now we can do things like encrypted cloud
backup and photo sharing in one request-response cycle over a secure
link.  In terms of making lives easier, this provides an end-to-end
(person to person) security and governance wrapper for the investors in
a Grameen context.

So, yes, if we had a business reason to create a generic replacement for
SSL or HTTPS, I would do it, I'm can almost do it now.  But we haven't,
so I won't, and my name's not google.

However, if there was *a competition for TLS2* where we could get a fair
hearing according to the rules, such as NIST's most famous AES
competition where even the guy who got knocked out within his own round
1 presentation walked away /with honour/ then we might have a go.  Not
because we'd win (resources, again) but because it would be fun, a great
learning and a chance to share.

It would be the best show the security world had ever seen.

Otherwise, it's left to google, who do have the industrial clout to play
the politics game that the IETFians so love and cherish.  What took me
10 years took them about 2.  Go guys!


> One of the things which demotivates volunteers (and open source
> projects are fundamentally very much like any other volunteer
> effort), is other people telling them that their work suck, and
> other people demanding that they be able to dictate how they spend
> their volunteer time.


Indeed.  And one of the things that demotivates potential contributors
is key personnel in open source projects telling them that their project
is totally open, while proving how closed it is.

All open source projects would gain more integrity and more contributors
if they said:  "This project is CLOSED.  There's the door, go look.  To
open the door, follow these instructions...."


> So if you tell me how I should spend my time, I'll tell you to f*ck
> off.


:)  On the Internet, when a dog barks, someone thinks their leg is being
pissed on, their knee jerks and they tell the dog to f*ck off.


> If you send me small, easily reviewable patches, each one which
> improves the code base, I'm much more likely to respond positively, or
> at least tell you why in my opinion, it might not be considered an
> improvement, and whether the patch can be changed so that it would be
> acceptable.  (But note that I'm not going to demand that you change
> the patch; only that this is the work that would be needed before I am
> willing to accept the patch; the difference is subtle, but important.)


Right.  Would be fine, as long as you didn't use the term "open"
anywhere near...


> Cheers,
> 
> 						- Ted
> 
> 
> 



iang, back to crypto code, coz it's almost working, yay!