Provable security not practical
Message # 1
Date: Sat, 01 Sep 2007
From: Ian G
To: practicalsecurity at hbarel.com
Subject: [PracticalSecurity] provable security not practical
Says Neal Koblitz, in amusing form, in his new commentary.
A critique of modern cryptography by Neal Koblitz in
"Notices of the AMS":
http://www.ams.org/notices/200708/tx070800972p.pdf
--
Perry E. Metzger perry at piermont.com
The Cryptography Mailing List
majordomo at metzdowd.com
The Practical Security mailing list
Message # 2
Date: Wed, 05 Sep 2007
From: "James A. Donald"
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Ian G wrote:
Says Neal Koblitz, in amusing form, in his newThe best of "provable security" proofs are not proofs,
commentary.
http://www.ams.org/notices/200708/tx070800972p.pdf
but arguments. Calling good arguments "proofs" rapidly
led to people tossing a bucket of random maths jargon
over bad arguments and calling them proofs.
The Practical Security mailing list
Message # 3
Date: Wed, 05 Sep 2007
From: Hagai Bar-El
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
On 05/09/07 04:00, James A. Donald wrote:
Ian G wrote:I tend to agree. The arguments that the math jargon is tossed at are not
Says Neal Koblitz, in amusing form, in his newThe best of "provable security" proofs are not proofs,
commentary.
http://www.ams.org/notices/200708/tx070800972p.pdf
but arguments. Calling good arguments "proofs" rapidly
led to people tossing a bucket of random maths jargon
over bad arguments and calling them proofs.
necessarily bad ones, but nonetheless they are just arguments...
The first warning sign that I saw for this phenomenon was that all the
proofs I've seen were all completely different from each other in their
structure, notation, etc.
So, I asked someone skilled in the art how I should form such proofs to
be "compliant". His answer was along the lines of: come up with some
meaningful notation, describe it and use it. Indeed, this may lead to a
diligent presentation of arguments, but not to a proof.
The problem with security proofs is that it is hard to prove non-events;
that is, that an event *can not* occur, following previous
argumentation. Obviously, once you defined a variable of a non-event (an
event not happening), you can use it further using the good-old logical
structures. However, the value of this "non-event" variable is tricky to
prove. For example: you can assert that "key is not available" ->
"decryption is not possible", following assumptions on cryptography
strength, but how will you establish the value of "key is not
available"? In most production cases you cannot really "prove" that "key
is not available", but only try to convince...
Hagai.
The Practical Security mailing list
Message # 4
Date: Wed, 05 Sep 2007
From: Ian G
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
James A. Donald wrote:
Ian G wrote:That would be Point 1. Also, they are then sold as
Says Neal Koblitz, in amusing form, in his newThe best of "provable security" proofs are not proofs,
commentary.
http://www.ams.org/notices/200708/tx070800972p.pdf
but arguments. Calling good arguments "proofs" rapidly
led to people tossing a bucket of random maths jargon
over bad arguments and calling them proofs.
important, or compliance tools. So as snake oil, they
distract people from the careful analysis needed to match
needs to features.
Point 3 is that the consume valuable time, so they destroy
opportunities to good work elsewhere.
I agree with your other point; they are indeed actively
harmful, on the whole.
I suppose the counter-argument would be a proof that was
valuable?
iang
The Practical Security mailing list
Message # 5
Date: Wed, 05 Sep 2007
From: Hagai Bar-El
To: Ian G
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
On 05/09/07 11:00, Ian G wrote:
James A. Donald wrote:You know, I would not discard the value of such "proofs" even though
Ian G wrote:That would be Point 1. Also, they are then sold as
Says Neal Koblitz, in amusing form, in his newThe best of "provable security" proofs are not proofs,
commentary.
http://www.ams.org/notices/200708/tx070800972p.pdf
but arguments. Calling good arguments "proofs" rapidly
led to people tossing a bucket of random maths jargon
over bad arguments and calling them proofs.
important, or compliance tools. So as snake oil, they
distract people from the careful analysis needed to match
needs to features.
Point 3 is that the consume valuable time, so they destroy
opportunities to good work elsewhere.
I agree with your other point; they are indeed actively
harmful, on the whole.
I suppose the counter-argument would be a proof that was
valuable?
they are not "proofs". They do not prove anything, but they do help you
analyze the security properties by some logic that, while not perfect,
is probably better than the typical "trust me" hand waving. If this is
what will make vendors analyze security more structurally, than so be
it. It will not be perfect, but it will be better than the empty slogans
we get today.
Also, from the point of view of the security analyst, such "proofs",
while not really proving anything, can still be a useful tool to help
you document and communicate your analysis.
Hagai.
The Practical Security mailing list
Message # 6
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: jtrjtrjtr2001 at yahoo.com, practicalsecurity at hbarel.com
Date: Fri, 07 Sep 2007
Subject: Re: [PracticalSecurity] provable security not practical
Sarad AV
I think some authors believe that their papers wouldn't get selected inNot speaking for any conference here, but one thing that excessive maths
conferences without the mathematical jargon. So, they would try to prove
something, no matter what. It would be interesting to know if conferences
accept papers just because of the presence of math. jargon in it.
jargon does it make it very hard to effectively review the paper for non-
jargonites (it acts as a type of obfuscation technique). As a result the
number of effective reviewers can drop dramatically. So one side-effect of
this is that it may make the papers a lot less accessible both to reviewers
and to readers, unless they're being specifically submitted to a conference
with a high percentage of mathematicians in attendance.
This may lead to a crypto-conference version of the bystander effect, you
assume that someone else has checked the jargon and therefore it must be OK.
Peter.
The Practical Security mailing list
Message # 7
Date: Fri, 07 Sep 2007
From: "James A. Donald"
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Ian G wrote:
I suppose the counter-argument would be a proof thatFor any proof to be valuable, need to be able to
was valuable?
distinguish between good proofs and bad proofs, need
some method or critique for excluding those "proofs of
security" that are merely weak arguments dressed in
irrelevant maths jargon - need some way of
distinguishing between those cases where the mathematics
actually adds rigor to the argument, and those cases
where it is mere fancy dress - need some way of
excluding those proofs that are the equivalent of an
advertisement where an actor dressed as a doctor
recommends the product.
For any "proof of security" to be valuable, have to lock
the doors against the alarmingly large number of
gatecrashers.
If no lock or door can be found, perhaps they are all
mere fancy dress.
The Practical Security mailing list
Message # 8
Date: Fri, 07 Sep 2007
From: "James A. Donald"
To: Peter Gutmann
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Peter Gutmann wrote:
Not speaking for any conference here, but one thingWhich assumption is likely to be true if the jargon is
that excessive maths jargon does it make it very hard
to effectively review the paper for non- jargonites
(it acts as a type of obfuscation technique). As a
result the number of effective reviewers can drop
dramatically. So one side-effect of this is that it
may make the papers a lot less accessible both to
reviewers and to readers, unless they're being
specifically submitted to a conference with a high
percentage of mathematicians in attendance.
(snip)
reasonably standard and used by diverse people to
communicate diverse things - likely to be true there is
a community that uses the jargon to communicate. Private
languages are a reliable indicator of madness. Languages
used by a small incestuous group are often pathological
science, and of course, one must also be wary of the
speaking in tongues effect. It is sometimes the case
that the entire jargon community may be using the jargon
for mere decoration.
The Practical Security mailing list
Message # 9
Date: Fri, 07 Sep 2007
From: Stephan Neuhaus
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
For any proof to be valuable, need to be able toMethinks that the only criterion by which a proof should be judged is =
distinguish between good proofs and bad proofs, =
whether it is correct or not.
Sure, there might be proofs that are unnecessarily hard to follow, there =
might even be proofs that actively try to obscure things, but in the =
end, all proofs are either correct or not (G=F6del nonwithstanding).
I must say that I am somewhat shocked by the opinions expressed in this =
forum. Yes, security proofs are special in the sense that they are =
about the real world and not about some mathematical artifact. That =
means that true proofs of security will be hard to come by because =
before the proof, there must be a modeling step that models what we want =
to prove, and such models are often not complete.
But *assuming* that the proof actually does prove what it sets out to =
prove, this gives us an enormous amount of confidence in the proved =
theorem (or piece of code or whatever), something that is hard to attain =
by any other means.
Therefore, to conclude that security proofs in general are actively =
harmful is going too far. What some perceive as the impenetrability of =
jargon may just be the honest attempt of the person doing the proof to =
create a (necessarily complex) model of the real world, so far as it =
affects his theorem. A perceived impenetrability of jargon may =
therefore merely be an unconscious inability to admit that one simply =
does not have the training to follow the proof.
Please note that I am an empiricist at heart, precisely because of the =
tremendous problems of obtaining real, true security proofs. But *when* =
we can get them, and *if* we interpret carefully what they say, they can =
be valuable additions to our toolset.
Fun,
Stephan
The Practical Security mailing list
Message # 10
Date: Sat, 8 Sep 2007
From: "Cuellar, Jorge"
To: "Stephan Neuhaus"
Subject: Re: [PracticalSecurity] provable security not practical
Thanks Stephan,
I wanted already to write a mail very much along the same lines. Besides wh=
at you have said, I would add: for much of the literature that we are discu=
ssing my frank opinion is that the authors are not trying to obscure things=
by the mathematical jargon. Just that this mathematical jargon is needed =
to express exactly what is meant.
Perhaps one reason why the discussion has been driving in this direction is=
that, at the end, many of the proofs are based on *conjectures*, like P <>=
NP, the Riemann Hypothesis, or the like. But to me, as to many mathematic=
ians, that a cryptographic solution is correct modulo one of those conjectu=
res, does indeed say a lot. For instance: if an attacker proves that one o=
f those "proven" protocols is incorrect, he does not have to waist his time=
with attacking the system. He will gain fame and wealth in much easier wa=
ys, see http://en.wikipedia.org/wiki/Clay_Mathematics_Institute#Millennium_=
Prize_Problems
Best,
Jorge
--
Jorge R Cuellar Siemens CT IC3
http://www.fm2008.abo.fi/
--
The Practical Security mailing list
Message # 11
Date: Sat, 08 Sep 2007
From: Ian G
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Hi guys,
replying to two at once:)
Cuellar, Jorge wrote:
Thanks Stephan,Sure, maybe, but the result is only intelligent to those who
...Just that this mathematical jargon is needed to express exactly what is meant.
understand it. That is, it is unintelligible to the outside
world.
As we are talking about security, the outside world can be
and should be extremely skeptical of things it does not
understand.
What does it mean to have a correct proof? It is totallyFor any proof to be valuable, need to be able toMethinks that the only criterion by which a proof should be judged is
distinguish between good proofs and bad proofs,
whether it is correct or not.
meaningless to me, and most others in this world, unless you
can tie that to some actual security objectives.
As we are talking security here, it has to be recognised
that the distance between a proof of mathematical elegence
and a security requirement is so far, so long, as to make
the relevance of a proof to a security requiremnt rather
questionable.
I must say that I am somewhat shocked by the opinions expressed in thisThe empirical world. With security proofs, there generally
forum. Yes, security proofs are special in the sense that they are
about the real world and not about some mathematical artifact. That
means that true proofs of security will be hard to come by because
before the proof, there must be a modeling step that models what we want
to prove, and such models are often not complete.
seems to be some reason why ... it fails to be generally
useful. So as a rule of thumb, ignore them. Empirically,
this delivers better results.
But *assuming* that the proof actually does prove what it sets out toI'm not saying that the guy who writes the proof is being
prove, this gives us an enormous amount of confidence in the proved
theorem (or piece of code or whatever), something that is hard to attain
by any other means.
Therefore, to conclude that security proofs in general are actively
harmful is going too far. What some perceive as the impenetrability of
jargon may just be the honest attempt of the person doing the proof to
(snip)
dishonest. I'm saying that the value that is added is
rather low, in a security terms. And therefore we have to
look at the cost of this, in direct terms (spend his salary
on a code reviewer...) and the indirect terms (false signals
sent to buyers).
As these direct and indirect costs are clear, present and
dangerous, and as the value of a security proof to security
is not clear, unrelatable and probably low, it follows that
the money is better spent elsewhere.
Therefore it is actively harmful. QED :)
Please note that I am an empiricist at heart, precisely because of theRight. Value however starts with money. We would have to
tremendous problems of obtaining real, true security proofs. But *when*
we can get them, and *if* we interpret carefully what they say, they can
be valuable additions to our toolset.
show that they are worth the money spent on them, and as
they are not free, nor are they reliable signals to an
outside world, the money can be better spent elsewhere.
iang
The Practical Security mailing list
Message # 12
Date: Sat, 08 Sep 2007
From: Hagai Bar-El
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
In this post I refer to the use of mathematical jargon, not yet to the
actual proofs this jargon is used to convey.
Like Stephan and Jorge, I tend not to attribute malicious intents to the
people who use math jargons in their papers. Of course, there are those
people who try to use math to add some "professional touch" to their
work that is otherwise unprofessional. There are also people who publish
papers on complete trivialities and there are people who publish papers
on complete nonsense. It is up to the "system" to maintain the proper
guards against these cases, such as by acceptance committees and by
reputation models. This is true for every part of the paper, not just
for the mathematic jargon.
The only problem with the math notation in security papers is when it is
called "a proof" (and treated as such), when everything it provides is
an explanation. I see nothing bad with using this jargon as long as the
reader (and the writer) consider it as a way of expression, and not as a
result for itself.
Security papers describe complex stuff. When people need to express
complex stuff they turn to methods of choice. Some people use complex
grammatical structures with sentences the length of a paragraph. Some
people prefer to use complex diagrams. Some people use mathematic
notation, a common tool for expressing complex stuff such as formulas.
I would not accuse the user of this or that method. He writes the paper
and it's his right to use mathematical jargon just as he is allowed to
use diagrams. It is our responsibility as skilled readers to see this
"jargon" as a language and base our perception of the paper on what this
language expresses rather than on what language was chosen by the author.
Hagai.
The Practical Security mailing list
Message # 13
Date: Sat, 08 Sep 2007
From: Hagai Bar-El
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Hi Ian,
On 08/09/07 17:36, Ian G wrote:
Skepticism can always add, of course, but you have to be...Just that this mathematical jargon is needed to express exactlySure, maybe, but the result is only intelligent to those who
what is meant.
understand it. That is, it is unintelligible to the outside world.
As we are talking about security, the outside world can be and should
be extremely skeptical of things it does not understand.
economically-intelligent about it. When enough understanding to exercise
healthy skepticism is an inch away, sure go that inch. However,
sometimes it is not economical, or even unfeasible. When I take the car
to the garage I ask the guy to explain what he's doing. I also read one
or two books about car mechanics and this is all I need to be able to
sanity check what the guy does under the hood. However, sometimes you
just need to let go and trust other "systems" to protect you. I have no
idea what the air-conditioner guy does inside my computerized A/C
system, but I trust his reputation. I have no idea if my home will not
break down on me when the wind blows, but I trust the standards
certification the engineer got for the building, etc. Jorge's examples
with bridges and medicine are even nicer.
The proofs need to be readable by those skilled in the art, not
necessarily by everyone. It seldom is, not only in security.
Not necessarily; depends on what you expect.What does it mean to have a correct proof? It is totally meaninglessFor any proof to be valuable, need to be able to distinguishMethinks that the only criterion by which a proof should be judged
between good proofs and bad proofs,
is whether it is correct or not.
to me, and most others in this world, unless you can tie that to some
actual security objectives.
As we are talking security here, it has to be recognised that the
distance between a proof of mathematical elegence and a security
requirement is so far, so long, as to make the relevance of a proof
to a security requiremnt rather questionable.
In usual math (or "in the lab") proofs take assumptions and assert
conclusions. In "real life" security, the useful proofs take much more
assumptions, sometimes ones you cannot attest to, but they still give
you the results to expect. In most cases it will not guarantee you
anything, because some of the assumptions it will use are ones you
cannot be sure of. However, it will tell you that at least some parts
are *likely* to be safe, depending on the extent to which you meet the
assumptions, and the extent to which the proof is complete.
Of course, the product may end up not being safe as a whole, but there
are very little (perhaps 'no'?) assurances in security and any help is
appreciated for you to do a better analysis job. Even if just *some* of
the process is known to be safe under *some* assumptions X, it is better
than no guarantees under assumptions X. And, if the entire system can be
"proven" under assumptions X, then it means that you can focus your
security money on assuring the applicability of assumptions X rather
than on checking the entire system.
The fact that you do not get a final result under any assumption set
does not mean that you get nothing of value.
Moreover, even if the proof is not a mathematical proof but just an
explanation, it can still be worth a lot. It tells you, someone skilled
in the art, what analysis the system has already gone through and what
were the results. It saves you work if you need to analyze it prior to
trusting it. Security analysis is almost never "complete" and is almost
never "final", so doing a good analysis is all about being economically
effective to the light of the risks, etc. Allowing you to shift your
analysis resources to other direction (if you agree with the analysis
that was communicated to you) is worth a lot of money.
When analyzing a file protection application I was very happy to focus
my analysis on other elements than verifying AES. AES has no real proof,
but I feel good enough with the "evidence" shown to me so to shift my
analysis efforts elsewhere in the system and thus give better return for
the money.
The empirical world. With security proofs, there generally seems toI don't agree. In the real world, there are very few "real" proofs that
be some reason why ... it fails to be generally useful. So as a rule
of thumb, ignore them. Empirically, this delivers better results.
have no "difficult" assumptions behind them. Thus, partial solutions,
such as proofs for only part of the system, or "proofs" that are not
really proofs but just try to sound convincing to those skilled in the
art, have an important role mankind's non-certain, risk-taking,
approximated-quality, engineering work.
Hagai.
The Practical Security mailing list
Message # 14
Date: Sun, 09 Sep 2007
From: Stephan Neuhaus
To: Ian G
Cc: practicalsecurity at hbarel.com, "Cuellar, Jorge"
Subject: Re: [PracticalSecurity] provable security not practical
Ian G wrote:
The empirical world. With security proofs, there generally seems to beI'd like to see evidence for your claim. Especially the "generally" part.
some reason why ... it fails to be generally useful.
Right. Value however starts with money. We would have to show thatNo, value does not start with money. The one side is the *value* and the
they are worth the money spent on them, and as they are not free, nor
are they reliable signals to an outside world, the money can be better
spent elsewhere.
other is the *cost*, and it is the relation of the former to the latter
that determines whether it is worthwhile to go to the trouble of
obtaining a real, true security proof. An entirely different kettle of
fish.
For example, I want the airbag deployment logic and many other
automobile security functions verified, with proofs. This can be done
and this is done routinely in the automotive industry. Apparently, the
auto industry is seeing a good cost/benefit relation here. You seem to
want to do without proofs altogether. So what would be your alternative
instead?
Stephan
The Practical Security mailing list
Message # 15
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: iang at systemics.com, neuhaus at st.cs.uni-sb.de
Date: Sun, 09 Sep 2007
Cc: practicalsecurity at hbarel.com, jorge.cuellar at siemens.com
Subject: Re: [PracticalSecurity] provable security not practical
Stephan Neuhaus
For example, I want the airbag deployment logic and many other automobileI don't really care if it's verified with proofs or by reading the entrails of
security functions verified, with proofs.
a chicken, I just want to know with a high level of certainty that it'll
protect me. Perhaps an over-generalisation, but looking at most of the crypto
technology that we use every day (SSH, SSL/TLS, PGP, and so on), all of it was
engineered, not proven. OTOH the stuff that's proven, not engineered (things
like group key management), doesn't seem to be doing much for us.
Overall I agree with Hagai's earlier comments:
The only problem with the math notation in security papers is when it is
called "a proof" (and treated as such), when everything it provides is an
explanation. I see nothing bad with using this jargon as long as the reader
(and the writer) consider it as a way of expression, and not as a result for
itself.
A proof, where it's valuable as a proof, is helpful. A proof where it's
included because doing so is trendy and all the other kids are doing it too
isn't necessarily useful. So you can't make a black-and-white statement,
sometimes they're useful, sometimes they're not.
A good article on the value of proofs is "Social Processes and Proofs of
Theorems and Programs" by Richard De Millo, Richard Lipton, and Alan Perlis in
the May 1979 CACM.
Peter.
The Practical Security mailing list
Message # 16
Date: Sun, 09 Sep 2007
From: "Cuellar, Jorge"
To: Peter Gutmann
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de
Subject: Re: [PracticalSecurity] provable security not practical
Hi Peter,
Perhaps an over-generalisation, but looking at most of the cryptoYes, this is an over-generalization: Many practical protocols have been
technology that we use every day (SSH, SSL/TLS, PGP, and so on), all
of it was engineered, not proven.
proved incorrect when trying to verify them, and this is why we have new
versions of them. This is true for SSL, IPsec-IKE, and many others.
A proof, where it's valuable as a proof, is helpful. A proof whereI agree.
it's included because doing so is trendy and all the other kids are
doing it too isn't necessarily useful. So you can't make a
black-and-white statement,sometimes they're useful, sometimes
they're not.
Best regards,
Jorge
The Practical Security mailing list
Message # 17
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: Jorge.Cuellar at siemens.com
Date: Sun, 09 Sep 2007
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de
Subject: Re: [PracticalSecurity] provable security not practical
"Cuellar, Jorge"
Many practical protocols have been proved incorrect when trying to verifyWhen was SSL (meaning SSLv3) proved "incorrect"? What critical security flaw
them, and this is why we have new versions of them. This is true for SSL,
does SSLv3 have that was fixed in TLS?
IPsec-IKE,IKEv1 was kludged, not engineered, so that doesn't count :-).
Peter.
The Practical Security mailing list
Message # 18
Date: Sat, 08 Sep 2007
From: "Cuellar, Jorge"
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Hi Ian,
well, I think it is impossible that all people only use those theorems
whose proofs they understand.
Sure, maybe, but the result is only intelligent to those whoWhat is the outside world? There is a notion of scientific consensus...
understand it. That is, it is unintelligible to the outside
world.
You do not have to learn lots of bio-chemistry to take a drug, if it is
the medical state-of-the-art for your problem.
As we are talking about security, the outside world can beIf an engineer does not understand the proof of Pythagoras theorem or
and should be extremely skeptical of things it does not
understand.
the main toerem of calculus, he should not construct bridges?
What does it mean to have a correct proof? It is totallyOh, that I can do.
meaningless to me, and most others in this world, unless you
can tie that to some actual security objectives.
The empirical world. With security proofs, there generallyI do not think that "empirical security" without mathematics offers too
seems to be some reason why ... it fails to be generally
useful. So as a rule of thumb, ignore them. Empirically,
this delivers better results.
much security.
I'm not saying that the guy who writes the proof is beingWas that the assumption or the conclusion?
dishonest. I'm saying that the value that is added is
rather low, in a security terms.
And therefore we have toI am not able to follow your argument. And for sure I do not agree.
look at the cost of this, in direct terms (spend his salary
on a code reviewer...) and the indirect terms (false signals
sent to buyers).
As these direct and indirect costs are clear, present and
dangerous, and as the value of a security proof to security
is not clear, unrelatable and probably low, it follows that
the money is better spent elsewhere.
Therefore it is actively harmful. QED :)
Using math tools we have found many bugs in security protocols, see
http://www.avispa-project.org and for instance (just one example)
http://www.avispa-project.org/library/IKEv2-DS.html.
And we have proven many protocols correct (modulo some assumptions, as
in all sciences, including engineering, medicine and chemistry).
Best regards,
Jorge Cuellar
Jorge R Cuellar Siemens CT IC 3
The Practical Security mailing list
Message # 19
Date: Sun, 09 Sep 2007
From: Ian G
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Cuellar, Jorge wrote:
Hi Ian,Sure. Science and theorems have their place. We use them
well, I think it is impossible that all people only use those theorems
whose proofs they understand.
all the time. What I'm suggesting here is a place where
science and theorems have met their match, so to speak.
Outside world is those who use security products.Sure, maybe, but the result is only intelligent to those whoWhat is the outside world? There is a notion of scientific consensus...
understand it. That is, it is unintelligible to the outside
world.
You do not have to learn lots of bio-chemistry to take a drug, if it is
the medical state-of-the-art for your problem.
Scientific consensus: The current scientific consensus that
I have seen is that the science community can run some
conferences, peer-review some papers, and make a difference
to security. That's the "consensus" apparently imported
from other successful areas.
As we've seen this view in action for some time, and the
security threats have arisen without challenge from this
process ... we have to ask ourselves what value this
scientific consensus is delivering?
Refer to the original paper that started the thread, that
makes the point better than I can.
Yes, in the static world of bridges, a theorom is nice.As we are talking about security, the outside world can beIf an engineer does not understand the proof of Pythagoras theorem or
and should be extremely skeptical of things it does not
understand.
the main toerem of calculus, he should not construct bridges?
Pythagoras helped bridges a lot. And we can construct a
long list of other sciences.
In security however, we have a different thing: an active,
learned enemy. Consider military science, which is the
closest match to security science. How many theorems are
there in that science, and how many of them are
mathematically proven, and how many of those have been
broken in the field?
It is certainly possible that some theorems in these
"aggressive" fields will be helpful. I particularly like
those of Shamir and Kerckhoffs. But these guys stopped
short of mathematics for their theorems, and well short of
"provability". By way of their examples:
https://www.financialcryptography.com/mt/archives/000147.html
https://www.financialcryptography.com/mt/archives/000195.html
Consider it this way: can it be done in a way that I canWhat does it mean to have a correct proof? It is totallyOh, that I can do.
meaningless to me, and most others in this world, unless you
can tie that to some actual security objectives.
understand it? Or do I have to dive in and learn the maths too?
If I can't understand it, then I can't rely on it, because I
don't understand its limitations. If I can't rely on it, I
can't then reliably put it into some real world scenario;
which must be done at some point.
Which is to say, if the proof is used internally to support
some analysis, some further activity, and never leaves the
team that works with this tool, that's fine. However, if a
claim is made that "this achieves security requirement X,
and it is proven by this mathematical proof" then that then
becomes a big problem. At some point you hit two barriers:
the people who have to build it and use it can't deal with
it, and the people who attack it can see the flaws, and use
the failure in understanding to breach it.
Just to be clear, ignoring "proofs" is what I am suggesting.The empirical world. With security proofs, there generallyI do not think that "empirical security" without mathematics offers too
seems to be some reason why ... it fails to be generally
useful. So as a rule of thumb, ignore them. Empirically,
this delivers better results.
much security.
Ignoring mathematics might be too much of a stretch. There
are plenty of mathematical models that might help, but they
are pretty much exclusively based on risk, so they are in
essence estimates. Using the word "proof" is therefore a
bit of a stretch.
And, I'd suggest that empirical security is basically about
trying stuff, seeing if it works, and keeping it. People
don't generally use mathematics in the choice of use & keep
SSL, versus, say, WAP, IPsec, IKE, etc. They simply put
them both in and use rough economics to handle the rest of
the choice.
Conclusion, of below argument.I'm not saying that the guy who writes the proof is beingWas that the assumption or the conclusion?
dishonest. I'm saying that the value that is added is
rather low, in a security terms.
It's economics: if the cost of the product (provingAnd therefore we have toI am not able to follow your argument. And for sure I do not agree.
look at the cost of this, in direct terms (spend his salary
on a code reviewer...) and the indirect terms (false signals
sent to buyers).
As these direct and indirect costs are clear, present and
dangerous, and as the value of a security proof to security
is not clear, unrelatable and probably low, it follows that
the money is better spent elsewhere.
Therefore it is actively harmful. QED :)
something) is greater than the benefit, don't do that.
Using math tools we have found many bugs in security protocols, seeOK, finding a bug I like. That's good, although I cannot
http://www.avispa-project.org and for instance (just one example)
http://www.avispa-project.org/library/IKEv2-DS.html.
easily understand the bug there from a quick glance, it
seems to be a bug that clashes with the requirements:
"We found an MITM but it doesn't change the secrecy of the key!"
But maybe I misunderstood it?
And we have proven many protocols correct (modulo some assumptions, asThis is where I find difficulties. If you are saying that
in all sciences, including engineering, medicine and chemistry).
the analysis by way of proofs has proven that it can find no
more bugs, then that's fine.
iang
The Practical Security mailing list
Message # 20
Date: Sun, 09 Sep 2007
From: Ian G
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de
Subject: Re: [PracticalSecurity] provable security not practical
Hi guys,
great debate :)
Cuellar, Jorge wrote:
Hi Peter,Yes, you can definately show "we found a bug". But what is
Perhaps an over-generalisation, but looking at most of the cryptoYes, this is an over-generalization: Many practical protocols have been
technology that we use every day (SSH, SSL/TLS, PGP, and so on), all
of it was engineered, not proven.
proved incorrect when trying to verify them, and this is why we have new
versions of them. This is true for SSL, IPsec-IKE, and many others.
much more difficult is to show an economic improvement.
That's where the value fails. In practical terms, SSLv2 and
SSHv1 were shown to have some flaws, but those flaws were
rarely if ever exploited. Fixing them proved much more
expensive than the combined weight of losses caused by those
flaws.
So, economically, we would be better off if we had stuck
with SSL v2 and the original SSH v1.
This is particularly poignant in context of phishing. Why
did we bother with all that really good protocol work on SSL
v1 => v2 => v3 => TLS, etc etc, but never bothered to fix
the simple bugs that cause phishing?
Science is one of the guilty parties to that crime.
(I know little about IPsec, etc, as that has never been
successful, and therefore ... economically not worth the
study :)
iang
The Practical Security mailing list
Message # 21
Date: Sun, 09 Sep 2007
From: Hagai Bar-El
To: Ian G
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de, "Cuellar,
Subject: Re: [PracticalSecurity] provable security not practical
Hi Ian,
On 09/9/2007 15:59, Ian G wrote:
By what you say, information security in general has no viable economicYes, this is an over-generalization: Many practical protocols have beenYes, you can definately show "we found a bug". But what is
proved incorrect when trying to verify them, and this is why we have new
versions of them. This is true for SSL, IPsec-IKE, and many others.
much more difficult is to show an economic improvement.
model. I'm afraid it will be hard for you to convince most people here. :)
It is hard to *prove* the economic value of finding the bug because it's
hard to *prove* the magnitude of the damage that could be caused by not
fixing the bug. In general, it's hard to estimate the value of flaws
that you fix because you cannot tell what would have happened hadn't you
fixed them. You speculate. Economy is full of speculations; you only try
to do these speculations as wisely as possible and to lean against as
many figures as you can find around you when doing them.
One way to estimate the value of a bug is by utilizing the underground,
using the cost of an exploit to determine the value of the fix. You
wrote about this back in February 2006 and it made enough sense for me
to actually remember it.
A bug has a value, so fixing it introduces an economic improvement.
That's where the value fails. In practical terms, SSLv2 andYou don't know this. You don't know what would have happened hadn't we
SSHv1 were shown to have some flaws, but those flaws were
rarely if ever exploited. Fixing them proved much more
expensive than the combined weight of losses caused by those
flaws.
So, economically, we would be better off if we had stuck
with SSL v2 and the original SSH v1.
moved to TLS etc. Perhaps the big thing would have been ISP employees
sniffing into traffic and selling credit card data. Perhaps it could be
people lurking around hot spots sniffing payment information.
You cannot really tell what messes we avoided by fixing the commonly
used protocols.
This is particularly poignant in context of phishing. WhyPhishing could be solved if the people who needed to care about it cared
did we bother with all that really good protocol work on SSL
v1 => v2 => v3 => TLS, etc etc, but never bothered to fix
the simple bugs that cause phishing?
enough about it. Bankers shift liability so will not bear the cost, and
browser writers don't have a large enough incentive. I believe this will
change soon.
But say we did as you suggest, and spent the time solving phishing
rather than "wasting out time" with TLS... You might have been raising
the same accusation about us spending so much effort playing with how
browsers point to websites and not enough efforts on protecting the data
that these browsers transport...
The fact that some bugs are still with us does not mean that fixing the
rest was a mistake.
(I know little about IPsec, etc, as that has never beenNo economic value / success to IPsec? Each and every day that I can work
successful, and therefore ... economically not worth the
study :)
away from the office rather than commute is an IPsec success for me.
Hagai.
The Practical Security mailing list
Message # 22
Date: Sun, 09 Sep 2007
From: Hagai Bar-El
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Hi Ian,
I will relate to just one issue, which I think is fundamental.
On 09/09/07 15:51, Ian G wrote:
. . .What is the outside world? There is a notion of scientific consensus...Outside world is those who use security products.
You do not have to learn lots of bio-chemistry to take a drug, if it is
the medical state-of-the-art for your problem.
Consider it this way: can it be done in a way that I canThe proofs do not need to be understood by the layman. They are to be
understand it? Or do I have to dive in and learn the maths too?
If I can't understand it, then I can't rely on it, because I
don't understand its limitations. If I can't rely on it, I
can't then reliably put it into some real world scenario;
which must be done at some point.
understood by other professionals. Understanding proofs is something
that most people cannot do and do not feel like doing. Society and
economics generated mechanisms so that people do not need to understand
proofs in order to enjoy their outcome.
To us, a straightforward proof is easy and fun to follow. But guess
what, most people do not enjoy it as much. Say that secure browsing was
100% proven, by mathematics or by whatever logic. Do you really think my
mother would read the paper providing the crystal-clear proof before
entering her bank account online?
Even when it comes not to formal proofs but to empirical evidence, do
you bother to access this information in all cases where you rely on it?
When your life relies on it? I bet you don't.
Instead, there are people who understand the proofs, as well as the
other available information in the art, and they disseminate their
understanding by this or that mechanism, to the masses. The masses
exercise some inevitable trust in these "knowledge distributors"; trust
that is based, to some extent, on some varying factor, and check the
information that they get just to some very mild extent.
I did not get to see the kinetic computation that provides the "proof"
that my car's break system is good enough for every reasonable speed and
weather, but I know that Mitsubishi Motors will not risk their business
providing an inadequate breaking systems, and the state checks this too
before letting me use the car. I did not check if my house walls are
made from a proven material by a proven method, because I trust the
government to do this before the state engineer signs the residence
permits, etc.
Even if secure browsing to the m-banking site was proven secure by some
method, my mother would still ask me, or the neighbor's son, before
logging in. So we are the ones who have to be convinced, not her.
If the proof is valid, and those skilled in the art can follow it and
are convinced by it, the proof, or explanation, has achieved its goal.
Hagai.
The Practical Security mailing list
Message # 23
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: Stephan Neuhaus
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Stephan Neuhaus wrote:For any proof to be valuable, need to be able to
distinguish between good proofs and bad proofs,
Methinks that the only criterion by which a proofThe trouble is, that with proofs of security, this is
should be judged is whether it is correct or not.
Sure, there might be proofs that are unnecessarily
hard to follow, there might even be proofs that
actively try to obscure things, but in the end, all
proofs are either correct or not (G?del
nonwithstanding).
not strictly true.
One is describing a complicated system. Ones
description is necessarily simpler than the actual
system, thus unavoidably obfuscates the actual system to
some extent. A well chosen description can obfuscate
the actual system to a very great extent.
Any proof of security has the form "assuming one can
trust X, one can then trust Y, Y being made from X".
However it is not totally apparent what X actually is in
practice. X may in fact consist of moving all the
questionable elements of one's system to the trusted
category - "assuming all the dubious parts of Y are
secure, Y is secure".
X should correspond to a set of well known attacks, so
that the proof readily translates to "My system cannot
be attacked except in the following way."
Well if X *did* correspond to a set of well known
attacks, everyone would use the same jargon for X -
which they don't. Therefore proofs of security, are not
proofs of security. They are proofs of something, but
it is not security. The trouble is, it is difficult to
say what a correct proof of security in fact proves, and
the more mathematical the proof sounds, the less one can
know what it proves.
Let us apply consider everyone's favorite whipping boy:
PKI
One can easily prove that PKI cannot be attacked except
in the ways that it is being attacked - but such proof
obfuscates the fact that such attacks are disturbingly
easy.
Is then the proof that PKI is secure true or false?
Well in one sense, it is obviously false. PKI is
alarmingly insecure. Yet the proof is correct -
correct, but false.
Thus the transparency of one's axioms, the real world,
real life, practical meaning, is important.
Mathematicising one's arguments means talking about
abstractions and idealizations, obscuring the whether
ones security assumptions are realistic or self serving.
Thus to be useful, a "proof of security" needs to be
cast in language that is as unmathematical as possible,
full of particular concretes, rather than seemingly
impressive mathematical terms. It will then convey
considerably more information, thus be better evidence
of actual security. It then, however, sounds more like
an argument, sounds less impressive. Perhaps
considerably less publishable. People are inclined to
say "That is an argument, not a proof, no mathematics in
it!"
But *assuming* that the proof actually does prove whatBut is this a proof, or a severely obfuscated argument?
it sets out to prove, this gives us an enormous amount
of confidence in the proved theorem (or piece of code
or whatever), something that is hard to attain by any
other means.
One wants one's real systems to be secure, not
mathematical terms who concrete meaning is not readily
apparent to be secure.
To the extent that the proof is in terms of entities
whose concrete practical real world meaning is not
altogether clear, it does not in fact give you much
confidence in actual security.
To actually give us enormous confidence, the proof needs
sound more like engineering than mathematics - it needs
to describe a well specified actual concrete system.
The proof needs to say "Here is why I think I think if
we build it this way, it will be protected against these
attacks" - the language of the proof needs to be as
close to real world things and real world examples as
possible. Dressing one's argument in mathematics gives
us less reason to believe the proposed system is secure,
not more reason.
When people say "proof", they are disinclined to believe
it to be a proof unless it sounds like mathematics. But
real cryptographic systems are recalcitrant, not easily
mathematized. The more it sounds like mathematics, the
less it tells us about real systems.
To actually give us enormous confidence, a proof of
security should sound as little like mathematics as
possible, rather than as much like mathematics as
possible.
The Practical Security mailing list
Message # 24
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Cuellar, Jorge wrote:
Perhaps one reason why the discussion has been drivingThat is precisely what is in dispute.
in this direction is that, at the end, many of the
proofs are based on *conjectures*, like P <> NP, the
Riemann Hypothesis, or the like.
Few proofs of security, possibly none, correspond to
your description. But they all *sound* as if they
correspond to your description - and that is the
problem. That many proofs of security, and it is hard
to say how many, sound like what they are not.
The Practical Security mailing list
Message # 25
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
The more a proof *sounds* like maths, the more
impressive it sounds - and the less it tells us about
actual security.
A useful proof should *be* maths, and rely on maths, but
it should not *sound* like maths.
The Practical Security mailing list
Message # 26
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Cuellar, Jorge wrote:
If an engineer does not understand the proof ofYes. An engineer who cannot understand one of the many
Pythagoras theorem or the main toerem of calculus, he
should not construct bridges?
proofs of the Pythagorean theorem, or the fundamental
theorem of calculus, has no business building bridges.
I understand those proofs, and would be alarmed if a
bridge was built by an engineer who did not understand
them. I would expect such a bridge to be at very high
risk of falling down.
The use of obscure jargons in the proofs of security,
jargons that are known only to a tiny group of people,
makes such proofs of limited value even if they are
entirely valid, quite apart from the difficulty of
discovering whether the alleged proof is a pile of moldy
bananas decorated with random maths gibberish.
More seriously, a proof can be entirely valid, and at
the same time simultaneously be a pile of moldy bananas
decorated with random maths gibberish: Some proofs of
security, when deciphered, amount to little more than
"if all the weak points of this system work, the system
will work", which is true, a "valid" proof, but not
particularly reassuring.
To be actually useful, a proof of security needs to be
expressed in language that is as close to engineering
practice as possible.
The more it sounds like maths, the less it demonstrates
security, and since it claims to be a proof of security,
the more it sounds like maths, the less it actually is
maths.
The Practical Security mailing list
Message # 27
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
What is a proof?
If a proof is an an argument that is compellingly
persuasive on careful thought and study, then proofs of
security are very useful, and we should use proofs
wherever we can.
If however, a proof is an argument decorated with
mathematical sounding jargon, then they are of little
practical value in cryptography.
To be compellingly persuasive about security, a proof
must be about real systems, and will therefore not
*sound* very mathematical.
The Practical Security mailing list
Message # 28
Date: Mon, 10 Sep 2007
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hagai Bar-El wrote:
Security papers describe complex stuff. When peopleQuite so. I agree entirely.
need to express complex stuff they turn to methods of
choice. Some people use complex grammatical structures
with sentences the length of a paragraph. Some people
prefer to use complex diagrams. Some people use
mathematic notation, a common tool for expressing
complex stuff such as formulas.
I would not accuse the user of this or that method. He
writes the paper and it's his right to use
mathematical jargon just as he is allowed to use
(snip)
But security is engineering. The more a proof sounds
like mathematics, and the less it sounds like discussion
of an engineering proposal, the less it is a proof of
security.
The Practical Security mailing list
Message # 29
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: iang at systemics.com, info at hbarel.com
Date: Mon, 10 Sep 2007
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de,
Subject: Re: [PracticalSecurity] provable security not practical
Hagai Bar-El
The proofs do not need to be understood by the layman. They are to beI think you need to break this down into three layers, not two. To
understood by other professionals.
"professionals" (I assume that means academics, referees, conference
attendees, ...) and "the masses" you need to add "implementors", which are
halfway between the two. If the implementors don't understand the security
argument (I'm going to use that term as a generalisation of "proof") then all
the work is for nothing, because it's the implementors that build the
applications, not the academics.
Here's a real-world example of this: There was a large-scale IPsec
implementation (actually there were several, but because of its huge user base
this one got the most attention) that got a certain basic aspect of the
protocol wrong (I'm being a bit vague here to avoid listing vendor names and
whatnot). In commenting on this, one of the principal IPsec authors said that
this issue was obvious and everyone knew about it, so there was no need to
document it anywhere. The rejoinder was that if it was so obvious, why were
implementations getting it wrong?
This was an issue that was (apparently) known to a few academics, but not to
anyone else. At the other end of the scale it doesn't matter if end users
know about it or not, but if the implementors don't know about it they'll get
it wrong, and that's exactly what happened. This is why I like IEEE security
standards so much, they include a fairly meticulous security argument
(rationale) to guide readers and implementors, so if there's any question
about something you can look at the rationale and see what's meant. With most
other standards (particulary RFCs), it's pretty much guesswork as to what many
of the things in there are supposed to do. It's no surprise then that
implementors get things wrong...
Peter.
The Practical Security mailing list
Message # 30
Date: Mon, 10 Sep 2007
From: "Cuellar, Jorge"
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
James A. Donald wrote:
elliptic curve cryptogabhy, she can not use it because she can not trust it?
Where is the border line?
Best regards,
Jorge
Cuellar, Jorge wrote:Good, that is great! And if your daughter (or mine) does not understand
If an engineer does not understand the proof ofYes. An engineer who cannot understand one of the many
Pythagoras theorem or the main toerem of calculus, he
should not construct bridges?
proofs of the Pythagorean theorem, or the fundamental
theorem of calculus, has no business building bridges.
elliptic curve cryptogabhy, she can not use it because she can not trust it?
Where is the border line?
Best regards,
Jorge
The Practical Security mailing list
Message # 31
Date: Mon, 10 Sep 2007
From: Ian G
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Cuellar, Jorge wrote:
James A. Donald wrote:
Cuellar, Jorge wrote:Good, that is great! And if your daughter (or mine) does not understand
If an engineer does not understand the proof ofYes. An engineer who cannot understand one of the many
Pythagoras theorem or the main toerem of calculus, he
should not construct bridges?
proofs of the Pythagorean theorem, or the fundamental
theorem of calculus, has no business building bridges.
elliptic curve cryptogabhy, she can not use it because she can not trust it?
Where is the border line?
Er, building is different to usage! Your daughter does not
build bridges, and mine doesn't write ECC crypto code.
I generally take ordinary competent programmers and put them
to work in cryptoplumbing.
For me, the border line is drawn at public key stuff. That
is the area where it gets too complex and we need a
specialist. But only to build the basic signing &
encryption blocks; everything using them should be done by
basic competent programmers.
And then, I design the systems very carefully to assume that
the public key stuff can fail. Anything I don't understand
is assumed as a failure point.
iang
The Practical Security mailing list
Message # 32
Date: Sun, 9 Sep 2007
From: Sarad AV
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
It is about trust. So, what should a reviewer do, when
they come across papers with a lot of unnecessary math
jargon in it?
Sarad.
--- Hagai Bar-Elwrote:
before letting me use the car. I did not check if myTake the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
house walls are
made from a proven material by a proven method,
because I trust the
government to do this before the state engineer
signs the residence
permits, etc.
http://mobile.yahoo.com/go?refer=1GNXIC
The Practical Security mailing list
Message # 33
Date: Wed, 5 Sep 2007
From: Sarad AV
To: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
I think some authors believe that their papers
wouldn't get selected in conferences without the
mathematical jargon. So, they would try to prove
something, no matter what. It would be interesting to
know if conferences accept papers just because of the
presence of math. jargon in it.
Sarad.
--- "James A. Donald"wrote:
Ian G wrote:Need a vacation? Get great deals
Says Neal Koblitz, in amusing form, in his newhttp://www.ams.org/notices/200708/tx070800972p.pdf
commentary.
The best of "provable security" proofs are not
proofs,
but arguments. Calling good arguments "proofs"
rapidly
led to people tossing a bucket of random maths
jargon
over bad arguments and calling them proofs.
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
The Practical Security mailing list
Message # 34
Date: Mon, 10 Sep 2007
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de, "Cuellar,
Subject: Re: [PracticalSecurity] provable security not practical
Hi Hagai,
Hagai Bar-El wrote:
Hi Ian,Yes, twice over :) I know it is hard to convince people of
On 09/9/2007 15:59, Ian G wrote:
By what you say, information security in general has no viable economicYes, this is an over-generalization: Many practical protocols have beenYes, you can definately show "we found a bug". But what is
proved incorrect when trying to verify them, and this is why we have new
versions of them. This is true for SSL, IPsec-IKE, and many others.
much more difficult is to show an economic improvement.
model. I'm afraid it will be hard for you to convince most people here. :)
this. But more or less, that's what I am saying: the
economic models of information security don't match what
people really do.
Or, more aggresively:
https://financialcryptography.com/mt/archives/000968.html
We have enough observational experience to say that there is
a serious problem with science and information security;
the two are not connected as well as other areas in the
sciences. This leads us to question why? Koblitz put his
finger on several things, and one of them (only) was '"the
power that an aura of mathematical certainty can have over
competitive solutions" a.k.a. provable security,' as I write
about in that post.
iang
The Practical Security mailing list
Message # 35
Date: Mon, 10 Sep 2007
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de, "Cuellar,
Subject: Re: [PracticalSecurity] provable security not practical
Hi Hagai,
On the validity of economic conclusions from security models.
Hagai Bar-El wrote:
It is hard to *prove* the economic value of finding the bug because it'sYes, that's one of the problems with economics in general,
hard to *prove* the magnitude of the damage that could be caused by not
fixing the bug. In general, it's hard to estimate the value of flaws
that you fix because you cannot tell what would have happened hadn't you
fixed them. You speculate. Economy is full of speculations; you only try
to do these speculations as wisely as possible and to lean against as
many figures as you can find around you when doing them.
you can't run the experiment so easily. However, there are
techniques. You can build up estimates based on close and
correlated activity.
For example, consider how many cryptographic breaks have
been found in systems. Not many, a few. Then, consider how
much value has been lost in these systems. Not much.
Relate that value loss across.
The problem with these exercises is that quite often we can
build a case where it suggests that the value that will be
lost is zero.
For example, we can look at MITM, which SSL was redesigned
with v2 to stop. Useful and reliable cases of
protocol-level MITM are extremely hard to find. When we do
find them (for example there is *some* speculation that it
is happening over wireless) we often discover that they are
hard to exploit and they are risky. And, consequently,
little money has been lost in them.
So, following this logic, if we could show that bug X would
over time cause losses of Y and Y was in excess of the cost
to fix, we really should fix bug X, right?
If you agree to that, consider that if bug X only caused
losses of Y' and that was *less than the cost to fix* then
we should also agree that we should not fix bug X?
Well, protocol MITMs as a loss category are practically
speaking a loss of zero. So by this logic, we should not
have ever gone to SSL v2, and should have stuck to the
original SSL v1 which was vulnerable to MITM.
There's obviously a problem with that logic ... because
nobody in the field will ever follow it. In the field of
cryptography and protocols, everyone generally tries to fix
all the bugs, *regardless of the cost*.
One way to estimate the value of a bug is by utilizing the underground,I don't recall writing about it :)
using the cost of an exploit to determine the value of the fix. You
wrote about this back in February 2006 and it made enough sense for me
to actually remember it.
But, the value to whom? That's the value to the guy who
exploits it, or to the vendor. It isn't however the value
to the person who loses money by the exploit.
A bug has a value, so fixing it introduces an economic improvement.Both of these questions can be examined, have been examined,
That's where the value fails. In practical terms, SSLv2 andYou don't know this. You don't know what would have happened hadn't we
SSHv1 were shown to have some flaws, but those flaws were
rarely if ever exploited. Fixing them proved much more
expensive than the combined weight of losses caused by those
flaws.
So, economically, we would be better off if we had stuck
with SSL v2 and the original SSH v1.
moved to TLS etc. Perhaps the big thing would have been ISP employees
sniffing into traffic and selling credit card data. Perhaps it could be
people lurking around hot spots sniffing payment information.
and I am happy to say, professionally, we got them right!
The result is:
(a) ISPs would not breach the protocols, but instead will
breach the root lists of the browsers to insert own roots,
and then do SSL proxying. They then datamine and sell the
results.
(b) wireless sniffing around hotspots is used for high value
targets only, and credit cards don't count as high value.
There's no proof of the above, but there is anecodotal
evidence of both happening. E.g., wireless hotspots are
being breached to steal inside information that will effect
court judgements in insurance claims.
Those who go for credit cards don't go to hotspots nor
protocol breaches. They go for (i) breaches of servers or
(ii) phishing. In contrast to people who are in the
cryptography field, crooks are very economically savvy.
You cannot really tell what messes we avoided by fixing the commonlyActually, I do know this, or I can predict it, within some
used protocols.
reasonable bounds. I've spent the last decade or so
examining the actual cases of various failures, and working
out what causes losses and what doesn't.
That's what we do in the payments world, as opposed to the
Internet security world. (James D is also heavily
influenced by that world, which might account for our
consistent alignment! Dunno about Peter G :)
Specifically, we can generally say that unless there is hard
value involved, a protocol bug won't necessarily be
exploited, as it is generally too hard to use. And, as
there are only a few hard cash systems on the net (webmoney,
maybe e-gold spring to mind), there is not a validated threat.
That is, credit card doesn't count as it is not hard cash,
and any general obfuscation mechanism would work well enough
for the time being. Over-doing the security in a payments
system is a well known pattern :)
Sure. But assume that the liability allocation failure isThis is particularly poignant in context of phishing. WhyPhishing could be solved if the people who needed to care about it cared
did we bother with all that really good protocol work on SSL
v1 => v2 => v3 => TLS, etc etc, but never bothered to fix
the simple bugs that cause phishing?
enough about it. Bankers shift liability so will not bear the cost, and
browser writers don't have a large enough incentive.
the state of the world (as we might agree it is). In that
world, what is the economic benefit of fixing the SSL protocol?
*If* SSL generates its economic benefit from ecommerce, and
if ecommerce generates losses of around 3bn per year in
phishing, can we show anything that is worth doing?
I believe this willI've been predicting class action suits against software
change soon.
vendors and banks for a long time. So long I've given up
predicting :)
But say we did as you suggest, and spent the time solving phishingRight. It's not a mistake, unless we can show that the
rather than "wasting out time" with TLS... You might have been raising
the same accusation about us spending so much effort playing with how
browsers point to websites and not enough efforts on protecting the data
that these browsers transport...
The fact that some bugs are still with us does not mean that fixing the
rest was a mistake.
economic value of it is actually a bad project. Fixing old
bugs, now that it is done, is sunk costs, so we no longer
care. Fixing new bugs requires an economic rationale.
Unfortunately, nobody does that, they simply fix all the
bugs regardless of the cost.
I mean, in the broad sense, of course :)(I know little about IPsec, etc, as that has never beenNo economic value / success to IPsec? Each and every day that I can work
successful, and therefore ... economically not worth the
study :)
away from the office rather than commute is an IPsec success for me.
iang
The Practical Security mailing list
Message # 36
Date: Mon, 10 Sep 2007
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus,
Subject: Re: [PracticalSecurity] provable security not practical
Hagai Bar-El wrote:
Hi Ian,Sure, but that's a long distance, it's not the real
I will relate to just one issue, which I think is fundamental.
On 09/09/07 15:51, Ian G wrote:
. . .What is the outside world? There is a notion of scientific consensus...Outside world is those who use security products.
You do not have to learn lots of bio-chemistry to take a drug, if it is
the medical state-of-the-art for your problem.
Consider it this way: can it be done in a way that I canThe proofs do not need to be understood by the layman. They are to be
understand it? Or do I have to dive in and learn the maths too?
If I can't understand it, then I can't rely on it, because I
don't understand its limitations. If I can't rely on it, I
can't then reliably put it into some real world scenario;
which must be done at some point.
understood by other professionals. Understanding proofs is something
that most people cannot do and do not feel like doing. Society and
economics generated mechanisms so that people do not need to understand
proofs in order to enjoy their outcome.
To us, a straightforward proof is easy and fun to follow. But guess
(snip)
audience, nor the real question. The relevant question is
whether the implementor would read the proof.
I'd say the answer is "maybe." The next question is whether
the implementor would understand the proof? "Unlikely."
Third: would the implementor create the code to implement
the proof? Fourth: would the maintainer and the feature
adder and the marketing manager have any idea that there is
a proof involved?
This is (of course) what happened with PKI, which James
calls everyone's favourite whipping boy. The stuff has
elegant logic. Unfortunately, the logic did not survive,
and implementors of browsers (from Netscape first release,
onwards until now) broke the model.
Hence, I would suggest that the presence of a proof ... that
must be read/understood/implemented/maintained ... is a good
indication of a failed system, in advance. Because the
implementors cannot be assumed away, and they can't follow
the proofs unless they are in clear, compelling logic terms.
If the proof is valid, and those skilled in the art can follow it andPart of the problem is of course that those skilled in the
are convinced by it, the proof, or explanation, has achieved its goal.
art are not really as skilled in the art as we would like
them to be. We use too many programmers who are not as good
as they say they are.
But that's not a complete damnation; even those who *are*
skilled in the art have trouble with some elements. E.g.,
in my programming I happily build protocols based on all the
basic techniques, but when I get to public key stuff I draw
the line and get a specialist to do the work. In
programming terms, it is fairly easy to understand what a
hash is, and a HMAC.
But not a public key signature or encryption... That stuff
is so messy that I can't even work out which one to use, let
alone how to implement it safely.
iang
The Practical Security mailing list
Message # 37
Date: Mon, 10 Sep 2007
From: Stephan Neuhaus
To: Peter Gutmann
Cc: practicalsecurity at hbarel.com, info at hbarel.com, Jorge.Cuellar at siemens.com
Subject: Re: [PracticalSecurity] provable security not practical
Peter Gutmann wrote:
it wrong, and that's exactly what happened. This is why I like IEEE securityThat is an excellent point. I have always wondered why standards are
standards so much, they include a fairly meticulous security argument
(rationale) to guide readers and implementors, so if there's any question
about something you can look at the rationale and see what's meant. With most
other standards (particulary RFCs), it's pretty much guesswork as to what many
of the things in there are supposed to do. It's no surprise then that
implementors get things wrong...
almost always written in a way that makes them hard to understand,
especially when it comes to security. I remember with horror the time
when someone put a SET specification on my desk after our company had
foolishly agreed to implement SET...
Fun,
Stephan
The Practical Security mailing list
Message # 38
Date: Mon, 10 Sep 2007
From: Stephan Neuhaus
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, "Cuellar, Jorge"
Subject: Re: [PracticalSecurity] provable security not practical
James A. Donald wrote:
What is a proof?I agree completely. You can very well substitute "security" for
If a proof is an an argument that is compellingly
persuasive on careful thought and study, then proofs of
security are very useful, and we should use proofs
wherever we can.
If however, a proof is an argument decorated with
mathematical sounding jargon, then they are of little
practical value in cryptography.
"cryptography".
To be compellingly persuasive about security, a proofI am not sure that I agree with that. Many proofs are technically
must be about real systems, and will therefore not
*sound* very mathematical.
easier (and flaws are more easily seen) when the argument is formalized.
So what usually happens is that there is a mapping from the
"non-formal" domain to some formalism, the proof is done in that
formalism and the result mapped back to the original domain.
That mapping must be done very carefully, and it is by nature non-formal
(otherwise it wouldn't be needed). Most of the time (in my experience)
it is the mapping which is faulty, not the proof. Typical examples
include: failing to account for concurrency, failing to account for
attack vectors other than the one specifically addressed, and so on.
Of course it is easy to create inaccurate mappings and then dazzle the
reader with mathematics in order to suggest a rigor that is not really
there. That may be the core of the problem.
Fun,
Stephan
The Practical Security mailing list
Message # 39
Date: Mon, 10 Sep 2007
From: Stephan Neuhaus
To: Ian G
Cc: practicalsecurity at hbarel.com, "Cuellar, Jorge",
Subject: Re: [PracticalSecurity] provable security not practical
Ian G wrote:
[On protocol-level MITM attacks in SSLv1 and how the loss from thatI agree completely. This is the only rational way to go about
attack vector is very nearly zero.]
So, following this logic, if we could show that bug X would over time
cause losses of Y and Y was in excess of the cost to fix, we really
should fix bug X, right?
If you agree to that, consider that if bug X only caused losses of Y'
and that was *less than the cost to fix* then we should also agree that
we should not fix bug X?
allocating resources to fixing bugs.
Well, protocol MITMs as a loss category are practically speaking a lossAnd here I disagree. I think you are not using your own argument
of zero. So by this logic, we should not have ever gone to SSL v2, and
should have stuck to the original SSL v1 which was vulnerable to MITM.
correctly. My stance as your adversary may very well be something like
this: "OK, there is a protocol flaw but it is hard to exploit, but now I
know that they won't fix this, so this hard-to-exploit protocol flaw
will be in the software for some considerable time, therefore I now have
an incentive to make its exploitation easier." Over time, the amortized
cost of exploiting the flaw may drop to zero, just as with buffer overflows.
Fun,
Stephan
The Practical Security mailing list
Message # 40
Date: Mon, 10 Sep 2007
From: "Cuellar, Jorge"
To: Ian G
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Ian G wrote:
Er, building is different to usage! Your daughter does notThat is also my point: if to use crypto algorithms you need to
build bridges, and mine doesn't write ECC crypto code.
understand the proofs or not, *or* if you program them you have to
understand them or not, *or* ...
The discussion was that proofs have a rather low value and are even
harmful... Therefore *who* has to understand the proofs? You wrote:
What does it mean to have a correct proof? It is totallySo, if *you* understand them then you will use the crypto and if not you
meaningless to me, and most others in this world, unless you
can tie that to some actual security objectives.
do not? Or you do not sell it your customers? Or what? And if the
scientific community accepts a proof, then what?
Best regards,
Jorge
The Practical Security mailing list
Message # 41
Date: Mon, 10 Sep 2007
From: Ian G
To: Stephan Neuhaus
Cc: Hagai Bar-El,
Subject: Re: [PracticalSecurity] provable security not practical
Stephan Neuhaus wrote:
Ian G wrote:Yes. In Internet security protocols, however, the way that
[On protocol-level MITM attacks in SSLv1 and how the loss from thatI agree completely. This is the only rational way to go about
attack vector is very nearly zero.]
So, following this logic, if we could show that bug X would over time
cause losses of Y and Y was in excess of the cost to fix, we really
should fix bug X, right?
If you agree to that, consider that if bug X only caused losses of Y'
and that was *less than the cost to fix* then we should also agree
that we should not fix bug X?
allocating resources to fixing bugs.
bugs are fixed is normally "fix all known bugs in protocol
regardless of cost. Ignore bugs above that."
If you find that surprising, try spending a few years asking
the browser vendors to fix their UI security bugs like
specifying the name of the CA on the chrome. I have. They
won't.
Sure, it was a simple argument and assumed time-value away.Well, protocol MITMs as a loss category are practically speaking aAnd here I disagree. I think you are not using your own argument
loss of zero. So by this logic, we should not have ever gone to SSL
v2, and should have stuck to the original SSL v1 which was vulnerable
to MITM.
correctly. My stance as your adversary may very well be something like
this: "OK, there is a protocol flaw but it is hard to exploit, but now I
know that they won't fix this, so this hard-to-exploit protocol flaw
will be in the software for some considerable time, therefore I now have
an incentive to make its exploitation easier." Over time, the amortized
cost of exploiting the flaw may drop to zero, just as with buffer
overflows.
But let's examine that.
The reason that MITMs specifically are costly to exploit is
not the code, but the fact that the *active* attack left
traces, in a way that eavesdropping does not. Now,
classically, this means that each individual attack leaves a
residual risk factor, and that only scales for low frequency
high value targets.
This is precisely the reason why we can predict that active
attacks on wireless lans will be relatively rare: the right
guy with the right gear can point at the perpetrator and
catch them in the act. Because attacker is broadcasting and
sending active packets.
Now, classically we used to say that MITMs on the network
wouldn't happen because of the same reason: we could track
the packets back to the machine. However, a couple of
things changed to make MITMs somewhat easier:
1. botnets created an easy supply of losable nodes, thus
untraceable.
2. MITMs moved up to the application layer -- phishing.
Quite whether 2. is a result of 1. or not I think a bit
difficult to untangle.
So, assuming the presence of phishing, my argument stands:
any effort in moving from SSL v1 => v2 is wasted because of
the presence of the MITM at the application layer. Only if
we are going to fix that will there be any point in fixing
the (harder to exploit) bug in the protocol.
iang
Message # 42
Date: Mon, 10 Sep 2007
From: Ian G
To: "Cuellar, Jorge"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus
Subject: Re: [PracticalSecurity] provable security not practical
Cuellar, Jorge wrote:
Ian G wrote:If your point is you need to understand the proofs to use
Er, building is different to usage! Your daughter does notThat is also my point: if to use crypto algorithms you need to
build bridges, and mine doesn't write ECC crypto code.
understand the proofs or not, *or* if you program them you have to
understand them or not, *or* ...
the algorithms, I would say, those algorithms should not be
used. Full stop.
That's because the vast majority of people in the system
will not be able to deal with the proofs, and that includes
those from implementors outwards.
E.g., in a bank payment system I was involved with, there
were 3-4 who understood the maths to the extent that they
could understand any proofs required. However, there were
something like 200 people in the building who could not ...
and that's before the system left the development & trial
phases ... those people were the problem. If you need a
proof to make some security claim, those people will bypass
the assumptions in order to break the proof.
(I'm not joking about this .. the people in the bank did in
fact break a major security property, right under the noses
of everyone concerned.)
The discussion was that proofs have a rather low value and are evenCorrect, that's how I act. I don't use it unless I
harmful... Therefore *who* has to understand the proofs? You wrote:
What does it mean to have a correct proof? It is totallySo, if *you* understand them then you will use the crypto and if not you
meaningless to me, and most others in this world, unless you
can tie that to some actual security objectives.
do not? Or you do not sell it your customers? Or what?
understand it. I don't sell it unless I understand it.
That's just me though; I can point to a CA that's really
upset over that attitude, coz I won't sign-off until the
users can understand it, and they keep pointing out that
other CAs don't explain anything to their users :)
The problem is in the world at large, which immediately
starts outside the crypto/maths area. Most security is
built, used and sold and broken without the people involved
really understanding it. Which means that the most
important tool we have is simplicity, and our worst enemy is
complexity.
The question then is what do proofs do for this? They
increase complexity, because their existance indicates
exceptions (assumptions).
E.g., A secret key algorithm does not need a proof to be a
secret key algorithm, it just needs to fit in the standard
black box for secret key algorithms (these days, 256 bits of
key material, 128 bits of text). So if a secret key
algorithm is offered with a proof, that's a worrying sign.
If the proof has to be understood in order to use it (e.g.,
a proof that suggests you avoid weak keys?), that algorithm
is dead.
And if theThat statement has little value ... to me at least ... in
scientific community accepts a proof, then what?
the field of information security. I suppose it is a bit
like gravity; we never were able to prove quite why it
works, but it has been working for as long as apples have
fallen off trees.
Consider RSA. We might agree that there are proofs
surrounding RSA. From time to time people mention that the
RSA problem is "proven" to be NP-complete, or something like
that.
However, the two things that are valuable about RSA are (a)
that it performs a transformation loosely known as public
key crypto, and (b) it has been doing it for a long time
without serious challenge.
What is unvaluable about RSA is that the transformation is
messy and cannot be black-boxed like secret key and the like.
What is completely unimportant from a user-perspective is
whether it is NP-complete or not. Proofs don't enter into
the calculation, this spot is all covered by (b) above.
iang
The Practical Security mailing list
Message # 43
Date: Mon, 10 Sep 2007
From: Ian G
To: Stephan Neuhaus
Cc: practicalsecurity at hbarel.com, "Cuellar, Jorge",
Subject: Re: [PracticalSecurity] provable security not practical
Stephan Neuhaus wrote:
Ian G wrote:Yes. In Internet security protocols, however, the way that
[On protocol-level MITM attacks in SSLv1 and how the loss from thatI agree completely. This is the only rational way to go about
attack vector is very nearly zero.]
So, following this logic, if we could show that bug X would over time
cause losses of Y and Y was in excess of the cost to fix, we really
should fix bug X, right?
If you agree to that, consider that if bug X only caused losses of Y'
and that was *less than the cost to fix* then we should also agree
that we should not fix bug X?
allocating resources to fixing bugs.
bugs are fixed is normally "fix all known bugs in protocol
regardless of cost. Ignore bugs above that."
If you find that surprising, try spending a few years asking
the browser vendors to fix their UI security bugs like
specifying the name of the CA on the chrome. I have. They
won't.
Sure, it was a simple argument and assumed time-value away.Well, protocol MITMs as a loss category are practically speaking aAnd here I disagree. I think you are not using your own argument
loss of zero. So by this logic, we should not have ever gone to SSL
v2, and should have stuck to the original SSL v1 which was vulnerable
to MITM.
correctly. My stance as your adversary may very well be something like
this: "OK, there is a protocol flaw but it is hard to exploit, but now I
know that they won't fix this, so this hard-to-exploit protocol flaw
will be in the software for some considerable time, therefore I now have
an incentive to make its exploitation easier." Over time, the amortized
cost of exploiting the flaw may drop to zero, just as with buffer
overflows.
But let's examine that.
The reason that MITMs specifically are costly to exploit is
not the code, but the fact that the *active* attack left
traces, in a way that eavesdropping does not. Now,
classically, this means that each individual attack leaves a
residual risk factor, and that only scales for low frequency
high value targets.
This is precisely the reason why we can predict that active
attacks on wireless lans will be relatively rare: the right
guy with the right gear can point at the perpetrator and
catch them in the act. Because attacker is broadcasting and
sending active packets.
Now, classically we used to say that MITMs on the network
wouldn't happen because of the same reason: we could track
the packets back to the machine. However, a couple of
things changed to make MITMs somewhat easier:
1. botnets created an easy supply of losable nodes, thus
untraceable.
2. MITMs moved up to the application layer -- phishing.
Quite whether 2. is a result of 1. or not I think a bit
difficult to untangle.
So, assuming the presence of phishing, my argument stands:
any effort in moving from SSL v1 => v2 is wasted because of
the presence of the MITM at the application layer. Only if
we are going to fix that will there be any point in fixing
the (harder to exploit) bug in the protocol.
iang
The Practical Security mailing list
Message # 44
Date: Mon, 10 Sep 2007
From: Hagai Bar-El
To: Peter Gutmann
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de,
Subject: Re: [PracticalSecurity] provable security not practical
Hello Peter,
On 10/9/2007 07:54, Peter Gutmann wrote:
Hagai Bar-ElYes, I agree.writes:
The proofs do not need to be understood by the layman. They are to beI think you need to break this down into three layers, not two. To
understood by other professionals.
"professionals" (I assume that means academics, referees, conference
attendees, ...) and "the masses" you need to add "implementors", which are
halfway between the two. If the implementors don't understand the security
argument (I'm going to use that term as a generalisation of "proof") then all
the work is for nothing, because it's the implementors that build the
(snip)
The proof, or explanation, should be understood by the relying party's
decision-making agent. This can either be the implementor, if the
relying party trusts it blindly, or the analyst doing the evaluation,
that the relying party trusts blindly.
Hagai.
The Practical Security mailing list
Message # 45
Date: Mon, 10 Sep 2007
From: Hagai Bar-El
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com, Stephan Neuhaus,
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
On 10/9/2007 02:19, James A. Donald wrote:
To be compellingly persuasive about security, a proofA proof, I believe, does not necessarily need to be about a real system.
must be about real systems, and will therefore not
*sound* very mathematical.
A proof can be of a component that consists for a small part of the
system. Of course, this proof does not imply on the security of the
entire system, but it nonetheless is an important component in the
overall evaluation of the system, whether this analysis of the entire
system is for the purpose of a "proof" or just for an "explanation". It
helps the analyst focus.
Hagai.
The Practical Security mailing list
Message # 46
Date: Mon, 10 Sep 2007
From: Hagai Bar-El
To: "James A. Donald"
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
On 10/9/2007 02:50, James A. Donald wrote:
I think that:I would not accuse the user of this or that method. HeQuite so. I agree entirely.
writes the paper and it's his right to use
mathematical jargon just as he is allowed to use
diagrams. It is our responsibility as skilled readers
to see this "jargon" as a language and base our
perception of the paper on what this language
expresses rather than on what language was chosen by
the author.
But security is engineering. The more a proof sounds
like mathematics, and the less it sounds like discussion
of an engineering proposal, the less it is a proof of
security.
If it is indeed a "proof", then it should look like math, and use the
common analytic tools that are used for proofs, with (possibly wide)
assumptions that are clearly stated. This is hard to do in security,
primarily because of the assumptions part, and that's why good security
proofs are hard to come by.
If it is an "explanation", then it can either look like math, or like a
discussion, or like a diagram, as the author believes conveys his
message best. The reader has the right to either be convinced or not.
Hagai.
The Practical Security mailing list
Message # 47
Date: Tue, 11 Sep 2007
From: "James A. Donald"
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
James A. Donald:
Hagai Bar-El wrote:But security is engineering. The more a proof sounds
like mathematics, and the less it sounds like
discussion of an engineering proposal, the less it is
a proof of security.
If it is indeed a "proof", then it should look likeWhen an engineer shows his bridge will stand, his
math.
demonstration uses math, but does not look or sound
much like a mathematical proof.
The Practical Security mailing list
Message # 48
Date: Tue, 11 Sep 2007
From: Hagai Bar-El
To: Ian G
Cc: practicalsecurity at hbarel.com, neuhaus at st.cs.uni-sb.de, "Cuellar,
Subject: Re: [PracticalSecurity] provable security not practical
Hi Ian,
On 10/09/07 12:07, Ian G wrote:
For example, we can look at MITM, which SSL was redesignedSomehow I knew you will bring MITM as an example... :)
with v2 to stop. Useful and reliable cases of
protocol-level MITM are extremely hard to find. When we do
find them (for example there is *some* speculation that it
is happening over wireless) we often discover that they are
hard to exploit and they are risky. And, consequently,
little money has been lost in them.
MITM, *at a hindsight* *could* indeed be considered as over-reaction of
the security industry. I am willing to accept this. However, there was
no way to tell this back then and there is barely a way to tell this
now. You could not tell that MITM will eventually end up being on the
stronger link of the chain. If, for example, we were all diligent enough
to solve the remote database attacks, and the phishing, and the
compromise of the desktop (we did not know back then that we are about
to fail in all these), then MITM could have ended up being your
weakest link after all, and the attackers would have used it, in spite
of its complexity, for lack of other ways to get at your data.
The point in short is that before you see all the security problems with
a system, and you never see this entire picture in advance, you cannot
tell where the weakest link will end up being. The only reason MITM is
not the hackers' attack of choice is that SQL injection to the database
back-end is way easier.
Also, consider that the industry is aiming at one-size-fits-all
solutions wherever possible. TLS is typically used for e-commerce
activities that do not involve too valuable of credentials, but the same
TLS is also used for access to most sensitive corporate data, etc. There
is no point in defining low-risk and high-risk protocols when their
implementation has the same cost.
There's obviously a problem with that logic ... becauseThe bugs are fixed without considering the financial benefit. This is
nobody in the field will ever follow it. In the field of
cryptography and protocols, everyone generally tries to fix
all the bugs, *regardless of the cost*.
just because the financial benefit cannot be determined when a flaw is
discovered. You do not know what will end up being the best attack venue
for the entire system, and, as opposed to when dealing with QA issues,
the flaws that are exploited are decided on by a skillful opponent, not
by chance or by anything you can apply probability theories on.
Whatever you leave open is what will be used against you, unless you
left a bigger hole somewhere else.
https://financialcryptography.com/mt/archives/000649.htmlOne way to estimate the value of a bug is by utilizing the underground,I don't recall writing about it :)
using the cost of an exploit to determine the value of the fix. You
wrote about this back in February 2006 and it made enough sense for me
to actually remember it.
But, the value to whom? That's the value to the guy whoThe value is, of course, to the buyer, who is the attacker. This value
exploits it, or to the vendor. It isn't however the value
to the person who loses money by the exploit.
*should* be correlated with the possible gain of the attacker buying it,
which is, in turn, the damage that the exploit (and hence the bug)
causes to us.
(a) ISPs would not breach the protocols, but instead willI am not sure how my ISP can breach my root list, which is locally
breach the root lists of the browsers to insert own roots,
and then do SSL proxying. They then datamine and sell the
results.
stored, but this is off topic.
(b) wireless sniffing around hotspots is used for high valueThis is by the present situation, but could not be told when decisions
targets only, and credit cards don't count as high value.
on mitigating MITM, or doing SSL in general, were made.
If you did not have SSL/TLS, a hidden Wifi PDA under a sofa in a cafe
for a day, collecting m-banking, e-commerce, etc. data could be useful.
Those who go for credit cards don't go to hotspots norThey are economically savvy, and they are also highly adaptive.
protocol breaches. They go for (i) breaches of servers or
(ii) phishing. In contrast to people who are in the
cryptography field, crooks are very economically savvy.
Hagai.
The Practical Security mailing list
Message # 49
Date: Tue, 11 Sep 2007
From: Hagai Bar-El
To: Sarad AV
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] provable security not practical
Hello,
On 10/9/2007 06:52, Sarad AV wrote:
It is about trust. So, what should a reviewer do, whenDecide by the contents and not by the syntax chosen.
they come across papers with a lot of unnecessary math
jargon in it?
Hagai.
The Practical Security mailing list
Message # 50
Date: Tue, 11 Sep 2007
From: Hagai Bar-El
To: Stephan