On the problem of trust and pseudo-crypto-security
[This is taken from what I posted in another group and in theme partly
repeats what I previously posted in sci.crypt. Pardon for the
repetition.]
In everyday life one almost always has to trust some people in certain
matters. Obviously no human society could exist, in which no one ever
trusts anybody else. In ancient times, in transmitting a secret message
through a personal courier, one had to trust the courier. Nowadays, in
transmitting a secret message through a crypto-processing system
(software and hardware) one has obviously to trust all its components
being free of human and physical errors as well as malicious
manipulations (backdoors, tamper, etc.). Could the trust in the two
cases be compared somehow? In particular, hypothetically assume that
one could presently send a secret message via both channels equally
fast and at the same cost and that the personal courier is quite
trustworthy in the common sense (e.g. one's own brother), would there
be a preference in the choice or is the matter entirely indifferent?
And why?
As far as I can see, there is a fundamental problem of trust in all
computer applications. But what should one properly do nowadays, when
computers are ubiquitously involved in almost everything of one's life?
Consciously bearing the problem in mind, how sure would one
(subjectively) assess the security of one's secret messages sent over
communication channels that are commonly employed? Or does one rather
prefer to hide one's head in the sand, which is one way of solving the
problem? The problem is IMHO extremely hard. However, what greatly
confounds me is that there even seems to be scarcely any sufficient
mention of it either in the media or in scientific literatures of
crypto. In the latter, one continues to see and admire very fine
theoretical advancements. In my personal opinion this has the adverse
effect of creating sort of a thought base that breeds among common
people illusions of security of employing certain implementations of
such theoretical stuffs, while the actual security in practice may not
be that high or even under circumstances be non-exsistent at all.
That is, most common people nowadays are living with
pseudo-(crypto-)security.
Re: On the problem of trust and pseudo-crypto-security
Am 04.04.2011 03:35, schrieb amzoti:
> Do you understand the term assurance (as in information assurance)?
>
> Have you ever studied the goals of defense-in-depth?
>
> Do you understand why defense-in-depth is a necessary, but not
sufficient notion and it is currently the best we have?
>
> Do you see yet new flaws in the proposed methods of solution?
>
> Why do those still coincide with the definition of assurance?
>
> Assurance has nothing to do with absolutes - never has, never will
and never should!
>
> Once you understand that term, all your questions will be answered.
>
> On the most basic level, do you believe that any cryptographic
solution or algorithm is safe?
My knowledge is very meagre so that I am unable to respond to most
questions of yours. On the other hand I think I do understand something
about assurance as a general term (though not 'information assurance'),
for I have a health assurance (concerning payments of doctors' bills)
and an assurance against accidentally causing damages to other persons
as well as a few other assurances.
You seem to have misunderstood my post to mean that I had asked for
something 'absolute'. I certainly didn't ask for absolute security,
which should be clear from some wordings of mine in the original
post. Note in particular that even in case of having one's own brother
as courier of a secret message, there is a non-zero risk of betrayal.
Nothing can be absolutely sure, otherwise Murphy's Law also wouldn't
make much sense.
My main point is that the public seems to be under a strong impression
that digital signatures in the currently realized form provides a
very high degree of security, which IMHO however could be simply a pure
illusion. The public is by nature very limited in its knowledge
specific to any branch of sciences, in this case crypto. They see much
research work done by a large number of scientists and the voluminous
laws and regulations in connection with digital signatures elaborated
by the governments and the seemingly well functioning worldwide network
of CAs and hences would very naturally assume that the security
concerned is very well in order. (This is actually the same with the
issue of nuclear energy. But now see what has happened in Japan!)
I mean in the case of modern communication technology the public should
be 'adequately and clearly' informed that there do exist certain real
risks so that they could at least in certain special situations more
properly decide whether they would like to employ such communication
channels in preference to alternatives that may be more costly or
inconvenient in comparison.
M. K. Shen
------------------------------------------------------------------------
[The following text, which stems from what I posted earlier to
sci.crypt, is intended only for readers of comp.security.misc.
My apology to readers of sci.crypt for seeing the stuff again.
BTW, readers of sci.crypt may be interested in a recent thread
in comp.security.misc initiated by Gilles Ganault on a certain
SSL breach.]
Feasibility of backdoors in RSA key generation
Recently in discussions with some persons on feasibility of backdoors in
proprietary (non-opensource) software for RSA key generation, I pointed
out the possibility of having one or more real-valued r such that,
choosing q in the neighbourhood of r*p in key generation, one could
easily factor N=p*q with the knowledge of r. Another person (maaartin)
subsequently proposed a more versatile, principally simple and yet
apparently hard to detect backdoor. He suggested first generating a
random number RN of the magnitude of the key desired, then using the
first half of the bits of RN to (in a suitably choosen way) determine
a prime p, and finally finding a prime q that is close to RN/p, giving
N=p*q as the RSA key required.
The secret knowledge needed for an easy factorization of N of course is
the algorithm of computing p, which is apparently fairly widely open to
individual creativeness. It may be remarked that (1) the algorithm
needs not deliver only a unique candidate but can also produce a
limited number of alternative candidates of p for random selection and
(2) the input to the algorithm could be a combination of the first half
of the bits of RN together with some other (partly variable)
informations, e.g. the licence number of the software and the date and
time etc. (These would render detection of a backdoor by examining the
pairs of p and q generated harder.)
According to information supplied by one person, most, if not all, CAs
(trust centres) use proprietary software from a few vendors like
Entrust, Certicom, RSA etc. How could one exclude potential existence
of backdoors in such blackbox-software that mafias or secret agencies
may eventually manage to implant? A scenario that could be fairly
critical IMHO is one in which a backdoor rests dormant all the time
until a critical moment (e.g. a worldwide financial crisis) arrives
that is particularly favourable for the bad guys to exploit in order
to reap the maximum profit or detrimental effects intended, causing
thereby also indirect effects through mass psychology etc.
A related issue is trustworthiness of CAs. A CA, whose service is used
exclusively within the domain of a firm or organization, can certainly
easily be a trustworthy one. Otherwise, how could one as a rule develop
trust towards a particular CA? In ancient times, secret messages were
carried by couriers that the sender personally knew very well. But what
does one nowadays as customer "really" know of a given CA that is
consciously or unconsciously and directly or indirectly involved? To my
knowledge CAs have in general to work together, forming a hierachy of
CAs. Thus a question worthy to be considered is: If CAs are involved in
international transactions of common business nature, how many (on
average) different CAs are normally "in effect" involved and hence are
to be directly or indirectly trusted? Note that, independent of the
trustworthiness of the CAs themselves, if e.g. one of the CAs involved
uses a defective software as described above, then there could be
serious problems.
It may be noted that there is a recent news of a start of open source
work on something parallelly important in informatics: "Open Source
Parallel Filesystem Group Launched in Europe", see http://www.hpcwire.com/offthewire/Op...112000729.html
One may also remember in this connection some motivations behind EU's
Galileo Project. For RSA key generation, ideal would be an opensource
code that is available to all CAs and that is verified to be correct
by modern techniques of program verification (a kernel of an operating
system has recently been verified that way). It seems to be realistic
that an authority that oversees the CAs could implement such a project.
Finally it may be stressed that, once the bad guys succeed to implant
a backdoor into a blackbox RSA key generation software that is used
by many CAs, all the other potentially possible attacks in connection
with certification would become superfluous, being more labourious in
undertaking.
Re: On the problem of trust and pseudo-crypto-security
Am 04.04.2011 12:09, schrieb Mok-Kong Shen:
> Am 04.04.2011 03:35, schrieb amzoti:
> > Do you understand the term assurance (as in information assurance)?
[snip]
> My knowledge is very meagre so that I am unable to respond to most
> questions of yours. On the other hand I think I do understand something
> about assurance as a general term (though not 'information assurance'),
> for I have a health assurance (concerning payments of doctors' bills)
> and an assurance against accidentally causing damages to other persons
> as well as a few other assurances.
[snip]
Sorry, shouldn't the word 'assurance' better be 'insurance' instead??
Re: On the problem of trust and pseudo-crypto-security
On Apr 4, 6:49*am, Mok-Kong Shen <mok-kong.s...@t-online.de> wrote:
> Am 04.04.2011 12:09, schrieb Mok-Kong Shen:> Am 04.04.2011 03:35, schriebamzoti:
> > *> Do you understand the term assurance (as in information assurance)?
>
> [snip]
>
> > My knowledge is very meagre so that I am unable to respond to most
> > questions of yours. On the other hand I think I do understand something
> > about assurance as a general term (though not 'information assurance'),
> > for I have a health assurance (concerning payments of doctors' bills)
> > and an assurance against accidentally causing damages to other persons
> > as well as a few other assurances.
>
> [snip]
>
> Sorry, shouldn't the word 'assurance' better be 'insurance' instead??
For someone with meager knowledge you do blather on.
Why phrase this last as a question? Look it up.
"Insurance" is about a contract in which you are paid to compensate
for loss. A secondary definition involves a guarantee that no loss
will
occur.
"Assurance" is about trust or confidence. As used here it is about
levels of certainty less than 100%.
Health _insurance_ is what you have. It does not provide any
_assurance_ that your health will remain good. It does provide
some _assurance_ that you can afford to pay for treatment.
If you've ever had an insurance claim rejected, then you have
first hand knowledge that assurance is not always 100%.
Re: On the problem of trust and pseudo-crypto-security
Am 04.04.2011 13:11, schrieb jbriggs444:
> On Apr 4, 6:49 am, Mok-Kong Shen<mok-kong.s...@t-online.de> wrote:
>> Am 04.04.2011 12:09, schrieb Mok-Kong Shen:> Am 04.04.2011 03:35, schrieb amzoti:
>>> > Do you understand the term assurance (as in information assurance)?
>>
>> [snip]
>>
>>> My knowledge is very meagre so that I am unable to respond to most
>>> questions of yours. On the other hand I think I do understand something
>>> about assurance as a general term (though not 'information assurance'),
>>> for I have a health assurance (concerning payments of doctors' bills)
>>> and an assurance against accidentally causing damages to other persons
>>> as well as a few other assurances.
>>
>> [snip]
>>
>> Sorry, shouldn't the word 'assurance' better be 'insurance' instead??
>
> For someone with meager knowledge you do blather on.
>
> Why phrase this last as a question? Look it up.
>
> "Insurance" is about a contract in which you are paid to compensate
> for loss. A secondary definition involves a guarantee that no loss
> will
> occur.
>
> "Assurance" is about trust or confidence. As used here it is about
> levels of certainty less than 100%.
>
> Health _insurance_ is what you have. It does not provide any
> _assurance_ that your health will remain good. It does provide
> some _assurance_ that you can afford to pay for treatment.
>
> If you've ever had an insurance claim rejected, then you have
> first hand knowledge that assurance is not always 100%.
Ok. But what is then the purpose/sense of 'information assurance'
without anything in the sense of an 'insurance'?? I recall that once
upon a time a very mighty politician of the world claimed that a bad
dictator elsewhere had extremely dangerous weapons and therefore a
war should be launched against this man. Later one of the subordinates
of the mighty politician admitted that that's not true but he himself,
as far as I know, has never retracted his claim and there was also no
consequences whatsoever for him for that lie. Should I understand such
things as 'information assurance'??
Re: On the problem of trust and pseudo-crypto-security
> My knowledge is very meagre so that I am unable to respond to most
> questions of yours. On the other hand I think I do understand something
> about assurance as a general term (though not 'information assurance'),
> for I have a health assurance (concerning payments of doctors' bills)
> and an assurance against accidentally causing damages to other persons
> as well as a few other assurances.
Assurance and insurance are different words and very different
things. Life insurance does not prevent you from dying. Property
insurance does not prevent hurricanes. Health insurance does not
prevent you from getting sick, except in the very minimal ways it
encourages preventive medicine by, say, paying for annual physicals
or programs to quit smoking. Insurance just pays bills. "Information
insurance" (possibly part of "business interruption insurance")
might pay the bills to have someone come in and remove a virus from
your business computer or help you recover from a crashed hard
drive, and try to piece together your records after the fact.
Information assurance is concerned with making sure (to a reasonable
level of confidence) that the information will be available when
needed (preventing denial-of-service attacks), that the information
will not be disclosed to unauthorized people (confidentiality), and
that the information will be accurate and not subject to tampering
(integrity).
A significant concern of information assurance involves protecting
the information from employees and equipment failures, so it would
address backups of data, redundant hardware, audit logs, and limiting
access of employees to what they need for their job. Part of this
involves having employees cross-check other employees.
It's going to be difficult for information assurance to protect the
information from political pressure from the the boss (or other
large-scale conspiracies) when he wants "Weapons of Mass Destruction"
found and demands that reports about a certain restaurant serving
chili that is a "Weapon of *** Destruction" be corrected.
> I mean in the case of modern communication technology the public should
> be 'adequately and clearly' informed that there do exist certain real
> risks so that they could at least in certain special situations more
> properly decide whether they would like to employ such communication
> channels in preference to alternatives that may be more costly or
> inconvenient in comparison.
I believe the biggest risk here comes from governments putting
political pressure (if not rubber hoses) on CAs and their employees,
not trojan horses in key generation.
> According to information supplied by one person, most, if not all, CAs
> (trust centres) use proprietary software from a few vendors like
> Entrust, Certicom, RSA etc. How could one exclude potential existence
> of backdoors in such blackbox-software that mafias or secret agencies
> may eventually manage to implant?
How many of these programs are run under a proprietary virus that
pretends to be an operating system?
>A scenario that could be fairly
> critical IMHO is one in which a backdoor rests dormant all the time
> until a critical moment (e.g. a worldwide financial crisis) arrives
> that is particularly favourable for the bad guys to exploit in order
> to reap the maximum profit or detrimental effects intended, causing
> thereby also indirect effects through mass psychology etc.
I do not believe that the bad guy can count on communication with
his backdoor all the time. The backdoor may be present all the
time, and the bad guy refrains from taking advantage of it until there
is a crisis, but CAs do not generate their own keys often enough to
ensure that one will be generated soon when a crisis is identified.
A reasonable CA when generating its own keys will not allow the machine
to have network access which a bad guy could use to "trigger" a back
door. Ideally the machine is booted once, the program generates a
new key and burns it to CD-ROM, and the machine is crushed. CAs don't
expire their own keys often enough for this to be a big expense.
Re: On the problem of trust and pseudo-crypto-security
Am 04.04.2011 17:02, schrieb Gordon Burditt:
>> My knowledge is very meagre so that I am unable to respond to most
>> questions of yours. On the other hand I think I do understand something
>> about assurance as a general term (though not 'information assurance'),
>> for I have a health assurance (concerning payments of doctors' bills)
>> and an assurance against accidentally causing damages to other persons
>> as well as a few other assurances.
>
> Assurance and insurance are different words and very different
> things. Life insurance does not prevent you from dying. Property
> insurance does not prevent hurricanes. Health insurance does not
> prevent you from getting sick, except in the very minimal ways it
> encourages preventive medicine by, say, paying for annual physicals
> or programs to quit smoking. Insurance just pays bills. "Information
> insurance" (possibly part of "business interruption insurance")
> might pay the bills to have someone come in and remove a virus from
> your business computer or help you recover from a crashed hard
> drive, and try to piece together your records after the fact.
Sofar I agree with you.
> Information assurance is concerned with making sure (to a reasonable
> level of confidence) that the information will be available when
> needed (preventing denial-of-service attacks), that the information
> will not be disclosed to unauthorized people (confidentiality), and
> that the information will be accurate and not subject to tampering
> (integrity).
I don't see why this couldn't more sensibly be put also under the term
'information insurance'. If e.g. an internet provider fails to provide
the services it promises in the contract, one could claim redemptions,
as far as I know. So all 'assurances' IMHO could be 'subsumed' under
'insurance', excepting the one particular limiting case where
'assurance' defacto means no 'assurance' whatsoever at all.
> A significant concern of information assurance involves protecting
> the information from employees and equipment failures, so it would
> address backups of data, redundant hardware, audit logs, and limiting
> access of employees to what they need for their job. Part of this
> involves having employees cross-check other employees.
See above.
> It's going to be difficult for information assurance to protect the
> information from political pressure from the the boss (or other
> large-scale conspiracies) when he wants "Weapons of Mass Destruction"
> found and demands that reports about a certain restaurant serving
> chili that is a "Weapon of *** Destruction" be corrected.
Good point. In crypto history one knows a case (officially remaining
a rumour, though) where a reknown crypto device producer was enticed
(unclear whether under political pressure or under the pressure
of big money) to build a backdoor in a bunch of devices to be used
by diplomats of a certain foreign country. Thus I think that the
probability of a not-opensource software of RSA key generation
containing a (probably for the most time dormant) backdoor may not
be negligibly small.
>> I mean in the case of modern communication technology the public should
>> be 'adequately and clearly' informed that there do exist certain real
>> risks so that they could at least in certain special situations more
>> properly decide whether they would like to employ such communication
>> channels in preference to alternatives that may be more costly or
>> inconvenient in comparison.
>
> I believe the biggest risk here comes from governments putting
> political pressure (if not rubber hoses) on CAs and their employees,
> not trojan horses in key generation.
I don't agree with you. For a country where the software producers are
located, both ways are equally feasible and there is no reason to
neglect one of them. For countries where no such producers are located
(this happens currently to be the majority of cases, if I don't err),
of course only one way remains to be taken.
Of course, the correct functioning of CAs is an equally important issue
as the correctness of the software (actually also the hardware) the CAs
use. Before both issues are satisfactorily solved, IMHO the current
digital signature system is of very dubious nature at the best. On the
other hand, I like to stress that the existence of the issue concering
CAs and the difficulty of its solution can certainly be no excuse for
closing one's eyes on the other essential issue.
>> According to information supplied by one person, most, if not all, CAs
>> (trust centres) use proprietary software from a few vendors like
>> Entrust, Certicom, RSA etc. How could one exclude potential existence
>> of backdoors in such blackbox-software that mafias or secret agencies
>> may eventually manage to implant?
>
> How many of these programs are run under a proprietary virus that
> pretends to be an operating system?
Good point. There are projects with names like 'Trusted Embeded
Computing' etc. I know barely anything about them but surmise that such
work is very hard to be done really satisfactorily. Anyway, how could
one know for sure that a given piece of hardware has not been
manipulated or does not naturally leak out some informations that could
be exploited with equipments that are sufficiently sophisticated? I
believe that that's technically doable with a sufficiently large
budget. However, I doubt that could ever be realistic for the CAs that
we currently have.
>> A scenario that could be fairly
>> critical IMHO is one in which a backdoor rests dormant all the time
>> until a critical moment (e.g. a worldwide financial crisis) arrives
>> that is particularly favourable for the bad guys to exploit in order
>> to reap the maximum profit or detrimental effects intended, causing
>> thereby also indirect effects through mass psychology etc.
>
> I do not believe that the bad guy can count on communication with
> his backdoor all the time. The backdoor may be present all the
> time, and the bad guy refrains from taking advantage of it until there
> is a crisis, but CAs do not generate their own keys often enough to
> ensure that one will be generated soon when a crisis is identified.
My point is that at the time of a crisis there are a number of
signatures that are currently valid. The bad guys can then start to
exploit their backdoors. It is not profitable for them to do that
kind of work prior to a crisis, for what they would reap in such a case
would likely be tiny fishes instead of the big ones and the chance
is quite substantial that thereby the backdoors would be detected and
hence no longer utilizable later.
> A reasonable CA when generating its own keys will not allow the machine
> to have network access which a bad guy could use to "trigger" a back
> door. Ideally the machine is booted once, the program generates a
> new key and burns it to CD-ROM, and the machine is crushed. CAs don't
> expire their own keys often enough for this to be a big expense.
At least in the schemes I described, there is no need of any 'trigger'
in your sense. Please re-read my original text once again concerning
backdoors of the kind described there.
Re: On the problem of trust and pseudo-crypto-security
On 2011-04-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 04.04.2011 17:02, schrieb Gordon Burditt:
>>> My knowledge is very meagre so that I am unable to respond to most
>>> questions of yours. On the other hand I think I do understand something
>>> about assurance as a general term (though not 'information assurance'),
>>> for I have a health assurance (concerning payments of doctors' bills)
>>> and an assurance against accidentally causing damages to other persons
>>> as well as a few other assurances.
>>
>> Assurance and insurance are different words and very different
>> things. Life insurance does not prevent you from dying. Property
>> insurance does not prevent hurricanes. Health insurance does not
>> prevent you from getting sick, except in the very minimal ways it
>> encourages preventive medicine by, say, paying for annual physicals
>> or programs to quit smoking. Insurance just pays bills. "Information
>> insurance" (possibly part of "business interruption insurance")
>> might pay the bills to have someone come in and remove a virus from
>> your business computer or help you recover from a crashed hard
>> drive, and try to piece together your records after the fact.
>
> Sofar I agree with you.
>
>> Information assurance is concerned with making sure (to a reasonable
>> level of confidence) that the information will be available when
>> needed (preventing denial-of-service attacks), that the information
>> will not be disclosed to unauthorized people (confidentiality), and
>> that the information will be accurate and not subject to tampering
>> (integrity).
>
> I don't see why this couldn't more sensibly be put also under the term
> 'information insurance'. If e.g. an internet provider fails to provide
> the services it promises in the contract, one could claim redemptions,
> as far as I know. So all 'assurances' IMHO could be 'subsumed' under
> 'insurance', excepting the one particular limiting case where
> 'assurance' defacto means no 'assurance' whatsoever at all.
It cannot be put under the term "information insurance" because it is no
such thing. Might as well call it "information cow". Just because two
words differ in just a few letters does not mean they are the same as
each other.
Insurance means that you are assured that you will be reimbursed for
expenses which arise out of some evet. And IP not providing services can
be sued, but that is not a contractual obligation to provide you with
indemnity should they not live up to their contract. Your knowledge of
the English language has failed you. Assurance cannot be subsumed under
insurance. The two words mean very different things.
>
>> A significant concern of information assurance involves protecting
>> the information from employees and equipment failures, so it would
>> address backups of data, redundant hardware, audit logs, and limiting
>> access of employees to what they need for their job. Part of this
>> involves having employees cross-check other employees.
>
> See above.
>
>> It's going to be difficult for information assurance to protect the
>> information from political pressure from the the boss (or other
>> large-scale conspiracies) when he wants "Weapons of Mass Destruction"
>> found and demands that reports about a certain restaurant serving
>> chili that is a "Weapon of *** Destruction" be corrected.
>
> Good point. In crypto history one knows a case (officially remaining
> a rumour, though) where a reknown crypto device producer was enticed
> (unclear whether under political pressure or under the pressure
> of big money) to build a backdoor in a bunch of devices to be used
> by diplomats of a certain foreign country. Thus I think that the
> probability of a not-opensource software of RSA key generation
> containing a (probably for the most time dormant) backdoor may not
> be negligibly small.
>
>>> I mean in the case of modern communication technology the public should
>>> be 'adequately and clearly' informed that there do exist certain real
>>> risks so that they could at least in certain special situations more
>>> properly decide whether they would like to employ such communication
>>> channels in preference to alternatives that may be more costly or
>>> inconvenient in comparison.
>>
>> I believe the biggest risk here comes from governments putting
>> political pressure (if not rubber hoses) on CAs and their employees,
>> not trojan horses in key generation.
>
> I don't agree with you. For a country where the software producers are
> located, both ways are equally feasible and there is no reason to
> neglect one of them. For countries where no such producers are located
> (this happens currently to be the majority of cases, if I don't err),
> of course only one way remains to be taken.
>
> Of course, the correct functioning of CAs is an equally important issue
> as the correctness of the software (actually also the hardware) the CAs
> use. Before both issues are satisfactorily solved, IMHO the current
> digital signature system is of very dubious nature at the best. On the
> other hand, I like to stress that the existence of the issue concering
> CAs and the difficulty of its solution can certainly be no excuse for
> closing one's eyes on the other essential issue.
>
>>> According to information supplied by one person, most, if not all, CAs
>>> (trust centres) use proprietary software from a few vendors like
>>> Entrust, Certicom, RSA etc. How could one exclude potential existence
>>> of backdoors in such blackbox-software that mafias or secret agencies
>>> may eventually manage to implant?
>>
>> How many of these programs are run under a proprietary virus that
>> pretends to be an operating system?
>
> Good point. There are projects with names like 'Trusted Embeded
> Computing' etc. I know barely anything about them but surmise that such
> work is very hard to be done really satisfactorily. Anyway, how could
> one know for sure that a given piece of hardware has not been
> manipulated or does not naturally leak out some informations that could
> be exploited with equipments that are sufficiently sophisticated? I
> believe that that's technically doable with a sufficiently large
> budget. However, I doubt that could ever be realistic for the CAs that
> we currently have.
>
>>> A scenario that could be fairly
>>> critical IMHO is one in which a backdoor rests dormant all the time
>>> until a critical moment (e.g. a worldwide financial crisis) arrives
>>> that is particularly favourable for the bad guys to exploit in order
>>> to reap the maximum profit or detrimental effects intended, causing
>>> thereby also indirect effects through mass psychology etc.
>>
>> I do not believe that the bad guy can count on communication with
>> his backdoor all the time. The backdoor may be present all the
>> time, and the bad guy refrains from taking advantage of it until there
>> is a crisis, but CAs do not generate their own keys often enough to
>> ensure that one will be generated soon when a crisis is identified.
>
> My point is that at the time of a crisis there are a number of
> signatures that are currently valid. The bad guys can then start to
> exploit their backdoors. It is not profitable for them to do that
> kind of work prior to a crisis, for what they would reap in such a case
> would likely be tiny fishes instead of the big ones and the chance
> is quite substantial that thereby the backdoors would be detected and
> hence no longer utilizable later.
>
>> A reasonable CA when generating its own keys will not allow the machine
>> to have network access which a bad guy could use to "trigger" a back
>> door. Ideally the machine is booted once, the program generates a
>> new key and burns it to CD-ROM, and the machine is crushed. CAs don't
>> expire their own keys often enough for this to be a big expense.
>
> At least in the schemes I described, there is no need of any 'trigger'
> in your sense. Please re-read my original text once again concerning
> backdoors of the kind described there.
>
> Thanks for your comments.
>
> M. K. Shen
>
>
Re: On the problem of trust and pseudo-crypto-security
Am 04.04.2011 19:24, schrieb unruh:
> On 2011-04-04, Mok-Kong Shen<mok-kong.shen@t-online.de> wrote:
>> Am 04.04.2011 17:02, schrieb Gordon Burditt:
>>>> My knowledge is very meagre so that I am unable to respond to most
>>>> questions of yours. On the other hand I think I do understand something
>>>> about assurance as a general term (though not 'information assurance'),
>>>> for I have a health assurance (concerning payments of doctors' bills)
>>>> and an assurance against accidentally causing damages to other persons
>>>> as well as a few other assurances.
>>>
>>> Assurance and insurance are different words and very different
>>> things. Life insurance does not prevent you from dying. Property
>>> insurance does not prevent hurricanes. Health insurance does not
>>> prevent you from getting sick, except in the very minimal ways it
>>> encourages preventive medicine by, say, paying for annual physicals
>>> or programs to quit smoking. Insurance just pays bills. "Information
>>> insurance" (possibly part of "business interruption insurance")
>>> might pay the bills to have someone come in and remove a virus from
>>> your business computer or help you recover from a crashed hard
>>> drive, and try to piece together your records after the fact.
>>
>> Sofar I agree with you.
>>
>>> Information assurance is concerned with making sure (to a reasonable
>>> level of confidence) that the information will be available when
>>> needed (preventing denial-of-service attacks), that the information
>>> will not be disclosed to unauthorized people (confidentiality), and
>>> that the information will be accurate and not subject to tampering
>>> (integrity).
>>
>> I don't see why this couldn't more sensibly be put also under the term
>> 'information insurance'. If e.g. an internet provider fails to provide
>> the services it promises in the contract, one could claim redemptions,
>> as far as I know. So all 'assurances' IMHO could be 'subsumed' under
>> 'insurance', excepting the one particular limiting case where
>> 'assurance' defacto means no 'assurance' whatsoever at all.
>
> It cannot be put under the term "information insurance" because it is no
> such thing. Might as well call it "information cow". Just because two
> words differ in just a few letters does not mean they are the same as
> each other.
>
> Insurance means that you are assured that you will be reimbursed for
> expenses which arise out of some evet. And IP not providing services can
> be sued, but that is not a contractual obligation to provide you with
> indemnity should they not live up to their contract. Your knowledge of
> the English language has failed you. Assurance cannot be subsumed under
> insurance. The two words mean very different things.
What I meant was not whether linguistically etc. one term subsumes the
other but rather this: For 'practical' purposes, if an assurance
doesn't lead to a way (or at least a real possibility) of obtaining
some redemptions or the like in case the assurance is not fulfilled,
then that 'assurance' defacto would mean nothing IMHO. If I 'assure'
you this and that and there is absolutely no means with which you could
influence what I subsequently do for you at all, would you consider
what I 'assure' you to be an 'assurance' (note anyway the underlying
assumption that we are foreign to each other)? Thus an assurance
starts to make practical sense, if it is a kind of those promises
that are commonly to be found in insurance contracts.
Re: On the problem of trust and pseudo-crypto-security
["Followup-To:" header set to comp.security.misc.]
On 2011-04-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 04.04.2011 19:24, schrieb unruh:
>> On 2011-04-04, Mok-Kong Shen<mok-kong.shen@t-online.de> wrote:
>>> Am 04.04.2011 17:02, schrieb Gordon Burditt:
>>>>> My knowledge is very meagre so that I am unable to respond to most
>>>>> questions of yours. On the other hand I think I do understand something
>>>>> about assurance as a general term (though not 'information assurance'),
>>>>> for I have a health assurance (concerning payments of doctors' bills)
>>>>> and an assurance against accidentally causing damages to other persons
>>>>> as well as a few other assurances.
>>>>
>>>> Assurance and insurance are different words and very different
>>>> things. Life insurance does not prevent you from dying. Property
>>>> insurance does not prevent hurricanes. Health insurance does not
>>>> prevent you from getting sick, except in the very minimal ways it
>>>> encourages preventive medicine by, say, paying for annual physicals
>>>> or programs to quit smoking. Insurance just pays bills. "Information
>>>> insurance" (possibly part of "business interruption insurance")
>>>> might pay the bills to have someone come in and remove a virus from
>>>> your business computer or help you recover from a crashed hard
>>>> drive, and try to piece together your records after the fact.
>>>
>>> Sofar I agree with you.
>>>
>>>> Information assurance is concerned with making sure (to a reasonable
>>>> level of confidence) that the information will be available when
>>>> needed (preventing denial-of-service attacks), that the information
>>>> will not be disclosed to unauthorized people (confidentiality), and
>>>> that the information will be accurate and not subject to tampering
>>>> (integrity).
>>>
>>> I don't see why this couldn't more sensibly be put also under the term
>>> 'information insurance'. If e.g. an internet provider fails to provide
>>> the services it promises in the contract, one could claim redemptions,
>>> as far as I know. So all 'assurances' IMHO could be 'subsumed' under
>>> 'insurance', excepting the one particular limiting case where
>>> 'assurance' defacto means no 'assurance' whatsoever at all.
>>
>> It cannot be put under the term "information insurance" because it is no
>> such thing. Might as well call it "information cow". Just because two
>> words differ in just a few letters does not mean they are the same as
>> each other.
>>
>> Insurance means that you are assured that you will be reimbursed for
>> expenses which arise out of some evet. And IP not providing services can
>> be sued, but that is not a contractual obligation to provide you with
>> indemnity should they not live up to their contract. Your knowledge of
>> the English language has failed you. Assurance cannot be subsumed under
>> insurance. The two words mean very different things.
>
> What I meant was not whether linguistically etc. one term subsumes the
> other but rather this: For 'practical' purposes, if an assurance
> doesn't lead to a way (or at least a real possibility) of obtaining
> some redemptions or the like in case the assurance is not fulfilled,
> then that 'assurance' defacto would mean nothing IMHO. If I 'assure'
No. Not at all. I may well trust that the person will try their best to
do what they say. I may be wrong, and if so I absorb the cost. I could
sue, but since a suit would cost factors of 100 or more more than I
would recover it is not worth it.
Assurance is NOT insurance, and there is no reason linguistically or
otherwise to subsume one under the other. They are different words
because they cover different concepts.
> you this and that and there is absolutely no means with which you could
> influence what I subsequently do for you at all, would you consider
> what I 'assure' you to be an 'assurance' (note anyway the underlying
Sure I would. If I felt that you are an honourable person, your
assurance may be all I need.
> assumption that we are foreign to each other)? Thus an assurance
> starts to make practical sense, if it is a kind of those promises
> that are commonly to be found in insurance contracts.
Insurance contracts are not promises about what is being insured. They
are contracts about the losses incurred in incidents described in the
contract. They have nothing to do with the thing itself.
This argument is pointless. You do not undestand English. You do not
understand the law. But you want to discuss English legal concepts.
Re: On the problem of trust and pseudo-crypto-security
unruh <unruh@wormhole.physics.ubc.ca> wrote in
news:slrnipkbs5.ml1.unruh@wormhole.physics.ubc.ca:
> This argument is pointless. You do not undestand English.
> You do not understand the law. But you want to discuss
> English legal concepts.
Just to introduce a large red herring...
You DO know, I trust, that there is no such thing as a 'life
insurance' policy - there is only 'life assurance'. One can
only insure against a contingency - death is a certainty
(notwithstanding its date of occurence generally being
uncertain).
The better companies are careful about making the distinction.
Sadly, like so many other nuances in the language, it is being
lost through carelessness and ignorance - or worse,
deliberately, in the service of hucksterism (see below).
Yours in pedantry,
PS Even more sadly and to the even greater debasement of the
precision of the language, some insurance companies try to pass
off various products of theirs as offering life insurance versus
life assurance. O tempora, o mores!
Re: On the problem of trust and pseudo-crypto-security
unruh <unruh@wormhole.physics.ubc.ca> wrote in
news:slrnipkbs5.ml1.unruh@wormhole.physics.ubc.ca:
> This argument is pointless. You do not undestand English.
> You do not understand the law. But you want to discuss
> English legal concepts.
Just to introduce a large red herring...
You DO know, I trust, that there is no such thing as a 'life
insurance' policy - there is only 'life assurance'. One can
only insure against a contingency - death is a certainty
(notwithstanding its date of occurence generally being
uncertain).
The better companies are careful about making the distinction.
Sadly, like so many other nuances in the language, it is being
lost through carelessness and ignorance - or worse,
deliberately, in the service of hucksterism (see below).
Yours in pedantry,
PS Even more sadly and to the even greater debasement of the
precision of the language, some insurance companies try to pass
off various products of theirs as offering life insurance versus
life assurance. O tempora, o mores!
Re: On the problem of trust and pseudo-crypto-security
>> Information assurance is concerned with making sure (to a reasonable
>> level of confidence) that the information will be available when
>> needed (preventing denial-of-service attacks), that the information
>> will not be disclosed to unauthorized people (confidentiality), and
>> that the information will be accurate and not subject to tampering
>> (integrity).
>
> I don't see why this couldn't more sensibly be put also under the term
> 'information insurance'.
Information assurance is concerned with trying to *PREVENT* leaks.
Insurance is concerned with trying to pay for the damages after
leaks happen. You can try to prevent, say, Bin Laden (or some other
terrorist) getting the technology to build nuclear weapons. What
insurance company is going to have the resources to pay for the
damages when he blows up Washington DC and New York City (which
includes the New York Stock Exchange)? What amount of money would
make it up to the United States for the Soviet Union stealing nuclear
secrets after World War II?
> If e.g. an internet provider fails to provide
> the services it promises in the contract, one could claim redemptions,
> as far as I know.
Try reading one of the contracts. Most of them don't say you can
send even one email or download one web page. I'm sure all of them
disclaim consequential damages. You might be able to get a 1-month
refund of service when they fail to deliver an email concerning a
billion-dollar contract, but you won't get the profits you would
have had from the contract you lost. Chances are an ISP won't even
have anywhere near that amount money to pay off anyway.
> So all 'assurances' IMHO could be 'subsumed' under
> 'insurance', excepting the one particular limiting case where
> 'assurance' defacto means no 'assurance' whatsoever at all.
If you're satsified with letting terrorists kill people as long as
someone pays the bill, that might work. You might make more profit
putting out a notice that you'll let people kill your citizens for
a fixed price. If you're in government and that policy gets out,
you might find yourself out of office very quickly. Note that no
insurance companies insure against acts of war or nuclear accidents.
And if the terrorists kill *YOU*, you won't benefit from any payment.
>> A significant concern of information assurance involves protecting
>> the information from employees and equipment failures, so it would
>> address backups of data, redundant hardware, audit logs, and limiting
>> access of employees to what they need for their job. Part of this
>> involves having employees cross-check other employees.
>
> See above.
>>> I mean in the case of modern communication technology the public should
>>> be 'adequately and clearly' informed that there do exist certain real
>>> risks so that they could at least in certain special situations more
>>> properly decide whether they would like to employ such communication
>>> channels in preference to alternatives that may be more costly or
>>> inconvenient in comparison.
>>
>> I believe the biggest risk here comes from governments putting
>> political pressure (if not rubber hoses) on CAs and their employees,
>> not trojan horses in key generation.
>
> I don't agree with you. For a country where the software producers are
No, not software providers. The government puts political pressure
on the *CA* and *CA employees*. They don't need a fake certificate
if they can use the real one. Fake certificates can be detected.
(Bank of America uses a Chinese CA for its USA site? I don't think
so.) "Real" ones (actually generated by the CA) are harder to detect.
Are there any countries that do not have a CA? Certainly there are
a lot fewer that don't have a CA than those who don't have a software
producer that sells to CAs. Some governments run their own CAs that are
on the browser CA lists.
It's been demonstrated that CAs can and have issued false certificates
through carelessness (recent threads here discuss one such instance).
It certainly isn't inconceivable that the same could be accomplished
with pressure applied by a government, or for that matter, that the
instance being discussed was actually caused by pressure from a
government and the cover story when it was found out is carelessness.
I think it has also been demonstrated that CAs can and have issued false
certificates due to bribed employees. I do not have a cite for this.
There's a company called "Packet Forensics" that sells a 4-square-inch
product that can execute a meet-in-the-middle attack against SSL,
given a fake certificate. There's enough demand for these to make
it worthwhile for the company to market. Where do you think law
enforcement gets the certificates to make these devices work?
It has *NOT* been demonstrated that false certificates have been
created by using a backdoor in CA software.
Note that it is possible for browsers to detect fake certificates
(with some false positives), and I encourage browser authors to
consider implementing such a feature. The first time a browser
visits a SSL site, it logs the certificates in the chain of trust.
If it later visits the same site and sees *DIFFERENT* certificates,
it can generate a warning. There are several levels of such warnings:
(1) If the certificate was about to expire and the new one has the same
CA, it's likely just a renewal.
(2) If the certificate was NOT about to expire and the new one has the
same CA, well, I wonder a little.
(3) If the certificate has a different CA from before, I wonder more.
(4) If the certificate has a different CA in a different country,
I wonder even more.
(5) If the certificate keeps flopping back and forth between two different
CAs, now I really wonder.
(6) Give a stronger warning if it's a site that the user has marked
as "important". I care a lot if I'm going to a fake site pretending
to be my bank. I care less if I'm going to MySpace.
> located, both ways are equally feasible and there is no reason to
> neglect one of them. For countries where no such producers are located
> (this happens currently to be the majority of cases, if I don't err),
> of course only one way remains to be taken.
>>> According to information supplied by one person, most, if not all, CAs
>>> (trust centres) use proprietary software from a few vendors like
>>> Entrust, Certicom, RSA etc. How could one exclude potential existence
>>> of backdoors in such blackbox-software that mafias or secret agencies
>>> may eventually manage to implant?
Making a bank vault have a combination of 20 numbers instead of 10
won't be particularly effective until you fix the unlocked screen
door in the back of the vault. Government pressure on CAs and CA
employees is much more of a problem than trojan horses in CA key
generation software.
If you're worried about backdoors in software, worry about the back door
introduced by sending the CA a patch that's been tampered with (or
is completely made up). That might require developers to make the
backdoor and bribing one FedEx employee to intercept the official
patch and later deliver the modified one. Open source will not fix this.
In an old version of the Bell System Technical Journal, there is a
description of a hack made to a compiler that introduced a backdoor
password into the "login" program. All of the source code was
untampered with. If you recompiled login, you'd get the same binary
(with the backdoor). If you recompiled the compiler, you'd get the
same binaries (with the code that deliberately miscompiled particular
source code to introduce the backdoor). You can recompile the entire
system and nothing will change. And there's no evidence of the backdoor
in the source code.
Re: On the problem of trust and pseudo-crypto-security
>> This argument is pointless. You do not undestand English.
>> You do not understand the law. But you want to discuss
>> English legal concepts.
>
> Just to introduce a large red herring...
>
> You DO know, I trust, that there is no such thing as a 'life
> insurance' policy - there is only 'life assurance'. One can
"life assurance" would prevent you from dying. Or, at least, it
would prevent you from dying soon. There is no such thing. Or if
there is, it's an extensive program of preventative medicine, not
anything like a "policy" that you buy and put away in a safe
deposit box until you need to make a claim.
> only insure against a contingency - death is a certainty
> (notwithstanding its date of occurence generally being
> uncertain).
Life insurance is often sold to people who want to insure
against the contingency that they die *SOON* - before their
kids are on their own, and before their spouse dies. It
provides this.
>
> The better companies are careful about making the distinction.
> Sadly, like so many other nuances in the language, it is being
> lost through carelessness and ignorance - or worse,
> deliberately, in the service of hucksterism (see below).
>
> Yours in pedantry,
>
>
> PS Even more sadly and to the even greater debasement of the
> precision of the language, some insurance companies try to pass
> off various products of theirs as offering life insurance versus
> life assurance. O tempora, o mores!
>
>
Re: On the problem of trust and pseudo-crypto-security
>>> I don't see why this couldn't more sensibly be put also under the term
>>> 'information insurance'. If e.g. an internet provider fails to provide
>>> the services it promises in the contract, one could claim redemptions,
>>> as far as I know. So all 'assurances' IMHO could be 'subsumed' under
>>> 'insurance', excepting the one particular limiting case where
>>> 'assurance' defacto means no 'assurance' whatsoever at all.
Do you not at all recognize PREVENTION of an incident as a legitimate
tactic? Especially in cases where money will not make up for
information having been leaked?
In the USA we have a lot of convenience stores that sell groceries,
and often gas, and are open all night. They are often referred to
as Stop 'N Rob stores because of their reputation for getting robbed.
You are the manager of such a store. Your store gets robbed on the
average once a week for $10,000. About once a year there's a
shootout when one robber tries to steal what another robber is
already in process of stealing. What would you do?
(1) Buy an insurance policy against robbery, which would cost you
*AT LEAST* $52,000 a year, since the insurance company figures it
will have to pay off at least that much, and probably more, against
a run of higher-cost or more-frequent robberies, or your store clerk
getting killed. Buying insurance here is a losing proposition on
the average, but it protects you against financial loss due to a
bad run of robberies putting your store out of business.
OR
(2) Invest in some prevention: silent alarms, cameras, burglar
bars on the store, a better safe, bulletproof glass, send an employee
to the bank to deposit cash more often, and occasionally having an
armed guard patrol the area. There is NO assurance it will stop
*all* the robberies, in fact, it's highly improbable that it will.
But it might stop 3/4 of them, and reduce the take on those it
doesn't. This is perhaps knowable based on the track record of
other stores that did the same thing.
Now, if this costs $26,000, and it saves you $39,000 the first year,
you have a net savings of $13,000. In subsequent years you save more
as some of these actions don't have to be re-done every year (although
you might have to worry about someone stealing the cameras).
OR
(3) You can do a combination of both. The insurance company may insist
on this anyway or they won't insure you.
>> It cannot be put under the term "information insurance" because it is no
>> such thing. Might as well call it "information cow". Just because two
>> words differ in just a few letters does not mean they are the same as
>> each other.
>>
>> Insurance means that you are assured that you will be reimbursed for
>> expenses which arise out of some evet.
I strongly suspect that you CAN get business insurance that covers you
for liability for, among other things, leaking customer credit card info
from your web site. You will be required to meet standards for handling
this info, but if a breach occurs anyway, you can be insured against the
loss.
> What I meant was not whether linguistically etc. one term subsumes the
> other but rather this: For 'practical' purposes, if an assurance
> doesn't lead to a way (or at least a real possibility) of obtaining
> some redemptions or the like in case the assurance is not fulfilled,
> then that 'assurance' defacto would mean nothing IMHO. If I 'assure'
Prevention of the loss in the first place means nothing? Even if
it's not 100% certain? A safe cannot protect money with 100%
certainity because someone could guess the combination or use
explosives to get into it or force a manager to open it at gunpoint,
but banks and stores seem to spend money on them anyway.
Re: On the problem of trust and pseudo-crypto-security
Am 05.04.2011 08:12, schrieb Gordon Burditt:
>>> Information assurance is concerned with making sure (to a reasonable
>>> level of confidence) that the information will be available when
>>> needed (preventing denial-of-service attacks), that the information
>>> will not be disclosed to unauthorized people (confidentiality), and
>>> that the information will be accurate and not subject to tampering
>>> (integrity).
>>
>> I don't see why this couldn't more sensibly be put also under the term
>> 'information insurance'.
>
> Information assurance is concerned with trying to *PREVENT* leaks.
> Insurance is concerned with trying to pay for the damages after
> leaks happen. You can try to prevent, say, Bin Laden (or some other
> terrorist) getting the technology to build nuclear weapons. What
> insurance company is going to have the resources to pay for the
> damages when he blows up Washington DC and New York City (which
> includes the New York Stock Exchange)? What amount of money would
> make it up to the United States for the Soviet Union stealing nuclear
> secrets after World War II?
Well, my opinion is that it is not 'necessary' to strictly separate the
terms and it is quite convenient to lump them into one for most
discussions, including those of the present thread. Certainly there
are matters whose monetary values are so high to be put down as
numbers or are so difficult to be estimated that the errors of
estimation would render the numbers used of questionable value. A less
critical case than the example you mentioned is the insurance for
nuclear power plants. I know that in Germany the insurance companies
refuse to insure such power plants. I suppose this is so also in other
countries. The insurance companies are right, if one considers now the
accidents in Japan. However, 'defacto' there is an insurance. For the
insurance is 'actually' performed by the governments in their allowing
the plants to be built and in cases of accidents, e.g. now in Japan,
the costs of damages (or at least the lion's share of that) will be
taken by the governments, in other words, 'indirectly' taken by the
citizens by way of taxes. That's why I continue to think that for
topics like the present thread one needs, if at all, only the term
or concept of 'information insurance'.
>> If e.g. an internet provider fails to provide
>> the services it promises in the contract, one could claim redemptions,
>> as far as I know.
>
> Try reading one of the contracts. Most of them don't say you can
> send even one email or download one web page. I'm sure all of them
> disclaim consequential damages. You might be able to get a 1-month
> refund of service when they fail to deliver an email concerning a
> billion-dollar contract, but you won't get the profits you would
> have had from the contract you lost. Chances are an ISP won't even
> have anywhere near that amount money to pay off anyway.
>
>
>> So all 'assurances' IMHO could be 'subsumed' under
>> 'insurance', excepting the one particular limiting case where
>> 'assurance' defacto means no 'assurance' whatsoever at all.
>
> If you're satsified with letting terrorists kill people as long as
> someone pays the bill, that might work. You might make more profit
> putting out a notice that you'll let people kill your citizens for
> a fixed price. If you're in government and that policy gets out,
> you might find yourself out of office very quickly. Note that no
> insurance companies insure against acts of war or nuclear accidents.
> And if the terrorists kill *YOU*, you won't benefit from any payment.
(I suppose that these paragraphs may be considered to be covered by my
response above.)
>>> A significant concern of information assurance involves protecting
>>> the information from employees and equipment failures, so it would
>>> address backups of data, redundant hardware, audit logs, and limiting
>>> access of employees to what they need for their job. Part of this
>>> involves having employees cross-check other employees.
>>
>> See above.
>
>>>> I mean in the case of modern communication technology the public should
>>>> be 'adequately and clearly' informed that there do exist certain real
>>>> risks so that they could at least in certain special situations more
>>>> properly decide whether they would like to employ such communication
>>>> channels in preference to alternatives that may be more costly or
>>>> inconvenient in comparison.
>>>
>>> I believe the biggest risk here comes from governments putting
>>> political pressure (if not rubber hoses) on CAs and their employees,
>>> not trojan horses in key generation.
>>
>> I don't agree with you. For a country where the software producers are
>
> No, not software providers. The government puts political pressure
> on the *CA* and *CA employees*. They don't need a fake certificate
> if they can use the real one. Fake certificates can be detected.
> (Bank of America uses a Chinese CA for its USA site? I don't think
> so.) "Real" ones (actually generated by the CA) are harder to detect.
> Are there any countries that do not have a CA? Certainly there are
> a lot fewer that don't have a CA than those who don't have a software
> producer that sells to CAs. Some governments run their own CAs that are
> on the browser CA lists.
>
> It's been demonstrated that CAs can and have issued false certificates
> through carelessness (recent threads here discuss one such instance).
> It certainly isn't inconceivable that the same could be accomplished
> with pressure applied by a government, or for that matter, that the
> instance being discussed was actually caused by pressure from a
> government and the cover story when it was found out is carelessness.
> I think it has also been demonstrated that CAs can and have issued false
> certificates due to bribed employees. I do not have a cite for this.
>
> There's a company called "Packet Forensics" that sells a 4-square-inch
> product that can execute a meet-in-the-middle attack against SSL,
> given a fake certificate. There's enough demand for these to make
> it worthwhile for the company to market. Where do you think law
> enforcement gets the certificates to make these devices work?
In fact I have to heartily thank you for highly stressing the problems
that could arise on the side of CAs. I like to mention, however, that
I have also considered that issue in my note 'Feasibility of backdoors
in RSA key generation' with a paragraph starting with the sentence
'A related issue is trustwrothiness of CAs', though I didn't go as deep
as you into the issue with CAs, because I concentrated on the matter
stated in the title of the note. On the other hand, (sorry for
expressing my opinions in direct words) I have the vague impression
that you seem to want to 'play down' the issue of feasibility of
backdoors 'by all means'. I find that difficult to understand.
> It has *NOT* been demonstrated that false certificates have been
> created by using a backdoor in CA software.
What I pointed out is certainly only a possibility. But do you believe
that something that has not (yet) been demonstrated (1) has never
'actually' occured and (2) will never occur in future? Think e.g. of
the time 'before' the first accident of nuclear power plants was
reported in the media. Murphy's Law is BTW surely wellknown to you.
> Note that it is possible for browsers to detect fake certificates
> (with some false positives), and I encourage browser authors to
> consider implementing such a feature. The first time a browser
> visits a SSL site, it logs the certificates in the chain of trust.
> If it later visits the same site and sees *DIFFERENT* certificates,
> it can generate a warning. There are several levels of such warnings:
>
> (1) If the certificate was about to expire and the new one has the same
> CA, it's likely just a renewal.
> (2) If the certificate was NOT about to expire and the new one has the
> same CA, well, I wonder a little.
> (3) If the certificate has a different CA from before, I wonder more.
> (4) If the certificate has a different CA in a different country,
> I wonder even more.
> (5) If the certificate keeps flopping back and forth between two different
> CAs, now I really wonder.
> (6) Give a stronger warning if it's a site that the user has marked
> as "important". I care a lot if I'm going to a fake site pretending
> to be my bank. I care less if I'm going to MySpace.
Well, attacks could be at different levels. Take an analogy with the
banks: A gangster could get some money from a bank with a gun. A
defective manager of the bank could get away with possibly much more
money. So I don't understand why you neglect the potential risk of
there being backdoors in software. Certainly other measures like those
you pointed out are desirable and needed as well.
>> located, both ways are equally feasible and there is no reason to
>> neglect one of them. For countries where no such producers are located
>> (this happens currently to be the majority of cases, if I don't err),
>> of course only one way remains to be taken.
>
>>>> According to information supplied by one person, most, if not all, CAs
>>>> (trust centres) use proprietary software from a few vendors like
>>>> Entrust, Certicom, RSA etc. How could one exclude potential existence
>>>> of backdoors in such blackbox-software that mafias or secret agencies
>>>> may eventually manage to implant?
>
> Making a bank vault have a combination of 20 numbers instead of 10
> won't be particularly effective until you fix the unlocked screen
> door in the back of the vault. Government pressure on CAs and CA
> employees is much more of a problem than trojan horses in CA key
> generation software.
I don't understand. If a government could put pressure on CAs and CA
employees, couldn't it put pressure on software producers and software
producers' employees just as well?? Why should a government follow
one way while neglecting the other??
> If you're worried about backdoors in software, worry about the back door
> introduced by sending the CA a patch that's been tampered with (or
> is completely made up). That might require developers to make the
> backdoor and bribing one FedEx employee to intercept the official
> patch and later deliver the modified one. Open source will not fix this.
>
> In an old version of the Bell System Technical Journal, there is a
> description of a hack made to a compiler that introduced a backdoor
> password into the "login" program. All of the source code was
> untampered with. If you recompiled login, you'd get the same binary
> (with the backdoor). If you recompiled the compiler, you'd get the
> same binaries (with the code that deliberately miscompiled particular
> source code to introduce the backdoor). You can recompile the entire
> system and nothing will change. And there's no evidence of the backdoor
> in the source code.
I take 'however' from what you wrote as meaning I should 'additionally'
worry what you pointed out above, not I should now 'only' worry what you
pointed out and 'forget' what I have worried till the present. If this
is not what you intended, then please tell me in some more details
'why' I really should change my mind in your opinion.
Re: On the problem of trust and pseudo-crypto-security
Am 05.04.2011 10:08, schrieb Gordon Burditt:
>>>> I don't see why this couldn't more sensibly be put also under the term
>>>> 'information insurance'. If e.g. an internet provider fails to provide
>>>> the services it promises in the contract, one could claim redemptions,
>>>> as far as I know. So all 'assurances' IMHO could be 'subsumed' under
>>>> 'insurance', excepting the one particular limiting case where
>>>> 'assurance' defacto means no 'assurance' whatsoever at all.
>
> Do you not at all recognize PREVENTION of an incident as a legitimate
> tactic? Especially in cases where money will not make up for
> information having been leaked?
>
> In the USA we have a lot of convenience stores that sell groceries,
> and often gas, and are open all night. They are often referred to
> as Stop 'N Rob stores because of their reputation for getting robbed.
> You are the manager of such a store. Your store gets robbed on the
> average once a week for $10,000. About once a year there's a
> shootout when one robber tries to steal what another robber is
> already in process of stealing. What would you do?
>
> (1) Buy an insurance policy against robbery, which would cost you
> *AT LEAST* $52,000 a year, since the insurance company figures it
> will have to pay off at least that much, and probably more, against
> a run of higher-cost or more-frequent robberies, or your store clerk
> getting killed. Buying insurance here is a losing proposition on
> the average, but it protects you against financial loss due to a
> bad run of robberies putting your store out of business.
>
> OR
>
> (2) Invest in some prevention: silent alarms, cameras, burglar
> bars on the store, a better safe, bulletproof glass, send an employee
> to the bank to deposit cash more often, and occasionally having an
> armed guard patrol the area. There is NO assurance it will stop
> *all* the robberies, in fact, it's highly improbable that it will.
> But it might stop 3/4 of them, and reduce the take on those it
> doesn't. This is perhaps knowable based on the track record of
> other stores that did the same thing.
>
> Now, if this costs $26,000, and it saves you $39,000 the first year,
> you have a net savings of $13,000. In subsequent years you save more
> as some of these actions don't have to be re-done every year (although
> you might have to worry about someone stealing the cameras).
>
> OR
> (3) You can do a combination of both. The insurance company may insist
> on this anyway or they won't insure you.
>
>
>
>>> It cannot be put under the term "information insurance" because it is no
>>> such thing. Might as well call it "information cow". Just because two
>>> words differ in just a few letters does not mean they are the same as
>>> each other.
>>>
>>> Insurance means that you are assured that you will be reimbursed for
>>> expenses which arise out of some evet.
>
> I strongly suspect that you CAN get business insurance that covers you
> for liability for, among other things, leaking customer credit card info
> from your web site. You will be required to meet standards for handling
> this info, but if a breach occurs anyway, you can be insured against the
> loss.
>
>> What I meant was not whether linguistically etc. one term subsumes the
>> other but rather this: For 'practical' purposes, if an assurance
>> doesn't lead to a way (or at least a real possibility) of obtaining
>> some redemptions or the like in case the assurance is not fulfilled,
>> then that 'assurance' defacto would mean nothing IMHO. If I 'assure'
>
> Prevention of the loss in the first place means nothing? Even if
> it's not 100% certain? A safe cannot protect money with 100%
> certainity because someone could guess the combination or use
> explosives to get into it or force a manager to open it at gunpoint,
> but banks and stores seem to spend money on them anyway.
>
I like to concede the weakness of my arguments in 'assurance' vs
'insurance'. The debate on that, which IMHO has barely anything
essential to do with the topic of the thread, has taken up much time
of the readers, which is not desirable. May I request now my discussion
partners to kindly concentrate on issues more directly related to the
topic of the thread. Thanks in advance.
Re: On the problem of trust and pseudo-crypto-security
> (2) Invest in some prevention: silent alarms, cameras, burglar
> bars on the store, a better safe, bulletproof glass, send an employee
> to the bank to deposit cash more often, and occasionally having an
> armed guard patrol the area. There is NO assurance it will stop
> *all* the robberies, in fact, it's highly improbable that it will.
> But it might stop 3/4 of them, and reduce the take on those it
> doesn't. This is perhaps knowable based on the track record of
> other stores that did the same thing.
What a waste of effort. Spend a couple hundred bucks on a 12 gauge and hang
it behind the cash register. Get a nice Rottweiler chewing a piece of
rawhide sitting on the floor on a warm rug near the register. That only
costs you a thousand bucks one time charge-off plus cheap rug plus dog
food. I guarantee the crime will go down in that particular location.
Re: On the problem of trust and pseudo-crypto-security
Am 05.04.2011 11:18, schrieb Mok-Kong Shen:
> Am 05.04.2011 08:12, schrieb Gordon Burditt:
[snip]
>> Making a bank vault have a combination of 20 numbers instead of 10
>> won't be particularly effective until you fix the unlocked screen
>> door in the back of the vault. Government pressure on CAs and CA
>> employees is much more of a problem than trojan horses in CA key
>> generation software.
>
> I don't understand. If a government could put pressure on CAs and CA
> employees, couldn't it put pressure on software producers and software
> producers' employees just as well?? Why should a government follow
> one way while neglecting the other??
[snip]
On the other hand, hypothetically assuming that a government, that
could put pressure in both ways but that had nonetheless for some
unknown reasons to choose one single way, there are actually arguments
in favour of putting pressures on the side of software producers instead
of on the side of CAs: (1) There are less number of persons to be
pressured (backdoors affect many CAs using the same software), (2)
The time of exploitation is arbitrary and of long duration (a pressured
CA employee can only affect the certificates issued at the present
time, he may leave the firm and a successor has to be pressured),
(3) It may be very hard to influence CAs of foreign countries this way,
but with backdoors certificates of both home CAs and foreign CAs could
be equally exploited.
Of course, for a country without software producers in question, the
government has plainly no means of implanting such backdoors but is
on the contrary itself an object of backdoor attacks by a country that
has such software producers.
In this connection the historical rumour of backdoor implantation of
products of a crypto machine producer that helped to break diplomatic
communications of a foreign country may also be recalled.
Re: On the problem of trust and pseudo-crypto-security
> Just to introduce a large red herring...
In human clothing, apparently.
> You DO know, I trust, that there is no such thing as a 'life
> insurance' policy - there is only 'life assurance'. One can
> only insure against a contingency - death is a certainty
> (notwithstanding its date of occurence generally being
> uncertain).
Your English is shite. There is no such thing as "life assurance" but rest
assured, there /is/ a thing called a "life insurance policy". You have the
terms ***-backwards as you have been told repeatedly. Now I'm telling you.
> Yours in pedantry,
Not hardly! Pederasty, maybe! But that's your business until they catch you.
Re: On the problem of trust and pseudo-crypto-security
Fritz Wuehler
<fritz@spamexpire-201104.rodent.frell.theremailer.net> wrote
in
news:c03cbdd693e71cc157852d6150ccfd8a@msgid.frell. theremailer.
net:
In the words of the ancient Aztec sage, "Go **** yourself."
The correct term is life assurance, not life insurance. That
you perversely wish to persist in your error is of no concern to
me; it just confirms you're an obdurate as well as ignorant
arsehole.
Re: On the problem of trust and pseudo-crypto-security
On Tue, 05 Apr 2011 01:12:57 -0500, gordonb.j8bth@burditt.org (Gordon
Burditt) wrote:
<BIG snip>
> If you're worried about backdoors in software, worry about the back door
> introduced by sending the CA a patch that's been tampered with (or
> is completely made up). That might require developers to make the
> backdoor and bribing one FedEx employee to intercept the official
> patch and later deliver the modified one. Open source will not fix this.
>
Common OSS practice can. Although OSS could be delivered by any
method, in practice it is almost always downloaded, often from
multiple mirrors which can be compared, and sometimes signed (or at
least hashed) which can be checked -- if you bother.
Proprietary vendors usually download only from their own server, but
often use their own updater, which could (silently) check signatures.
Both of these protect only delivery from the developer(s) to the user,
not against flaws created either accidentally or intentionally by the
developer(s) or attacks on the development environment.
> In an old version of the Bell System Technical Journal, there is a
> description of a hack made to a compiler that introduced a backdoor
> password into the "login" program. All of the source code was
> untampered with. If you recompiled login, you'd get the same binary
> (with the backdoor). If you recompiled the compiler, you'd get the
> same binaries (with the code that deliberately miscompiled particular
> source code to introduce the backdoor). You can recompile the entire
> system and nothing will change. And there's no evidence of the backdoor
> in the source code.
Re: On the problem of trust and pseudo-crypto-security
In article <jpeaq6pc3it9dkkvdar8a4o2nnaiad6dhn@4ax.com>,
David Thompson <dave.thompson2@verizon.net> wrote:
>On Tue, 05 Apr 2011 01:12:57 -0500, gordonb.j8bth@burditt.org (Gordon
>Burditt) wrote:
><BIG snip>
>> If you're worried about backdoors in software, worry about the back door
>> introduced by sending the CA a patch that's been tampered with (or
>> is completely made up). That might require developers to make the
>> backdoor and bribing one FedEx employee to intercept the official
>> patch and later deliver the modified one. Open source will not fix this.
>>
>Common OSS practice can. Although OSS could be delivered by any
>method, in practice it is almost always downloaded, often from
>multiple mirrors which can be compared, and sometimes signed (or at
>least hashed) which can be checked -- if you bother.
The hash proves nothing, unless you also get the
hash out of band and securely. It can prevent
fat-finger errors, but offers no security at all.
Signatures are what is needed.
Re: On the problem of trust and pseudo-crypto-security
On 11-04-13 9:26 AM, Greg Rose wrote:
> In article<jpeaq6pc3it9dkkvdar8a4o2nnaiad6dhn@4ax.com >,
> David Thompson<dave.thompson2@verizon.net> wrote:
>> Common OSS practice can. Although OSS could be delivered by any
>> method, in practice it is almost always downloaded, often from
>> multiple mirrors which can be compared, and sometimes signed (or at
>> least hashed) which can be checked -- if you bother.
> The hash proves nothing, unless you also get the
> hash out of band and securely.
And that is how it is typically done. The download is done over HTTP,
while the hash is fetched with HTTPS from a site with a good certificate.
Cheers,
-j
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
Re: On the problem of trust and pseudo-crypto-security
Jeffrey Goldberg <jeffrey+news@goldmark.org> wrote:
>And that is how it is typically done. The download is done over HTTP,
>while the hash is fetched with HTTPS from a site with a good certificate.
Let me be the first to confess that I have never done that.
Re: On the problem of trust and pseudo-crypto-security
On 2011-04-14, Fritz Wuehler <fritz@spamexpire-201104.rodent.frell.theremailer.net> wrote:
>> The hash proves nothing, unless you also get the
>> hash out of band and securely.
>
> Not necessarily so...it could prove you got /exactly/ what the attacker
> intended. ;-)
Why out of band? That is what public key crypto is all about, with its
signing ability.
Re: On the problem of trust and pseudo-crypto-security
In article <slrniqcnfe.vka.unruh@wormhole.physics.ubc.ca>,
unruh <unruh@wormhole.physics.ubc.ca> wrote:
>On 2011-04-14, Fritz Wuehler
><fritz@spamexpire-201104.rodent.frell.theremailer.net> wrote:
>>> The hash proves nothing, unless you also get the
>>> hash out of band and securely.
>>
>> Not necessarily so...it could prove you got /exactly/ what the attacker
>> intended. ;-)
>
>Why out of band? That is what public key crypto is all about, with its
>signing ability.
Yes, that's why I said that you needed signatures,
and that hashes prove nothing.
Re: On the problem of trust and pseudo-crypto-security
On 11-04-13 1:12 PM, kg wrote:
> Jeffrey Goldberg<jeffrey+news@goldmark.org> wrote:
>> And that is how it is typically done. The download is done over HTTP,
>> while the hash is fetched with HTTPS from a site with a good certificate.
>
> Let me be the first to confess that I have never done that.
You may have if you use a product that has a reasonably well designed
updater. I wasn't talking about what individual people manually do; I
was speaking of updaters with software. They do this for you.
Sorry if I had misunderstand what we were talking about. You are
certainly correct that very few people actually check hashes or
signatures manually that way.
Cheers,
-j
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
On the problem of trust and pseudo-crypto-security 
Linear Mode
