Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
The bottom line is that S/MIME aims at a security level which is not
critical, while it can be perfectly operational for the bulk use of the
Internet today. A honest and correct appraisal of this fact must be more
useful than snake-oil, here too.
I absolutely agree. I was simply observing that it's quite possible
to create a profile of S/MIME that is usable in a high security
environment.
->
-> > ->S/MIME the protocol is perfectly usable in
-> > -> high security situations. As always, the implementation has to
-> > -> be secure. (Incidentally, all the security holes you mention with
-> > -> the exception of self-signed certs are easily solved by using a
-> > -> secure hardware token for one's own private keying material.)
-> >
-> > I must again disagree. It is a common misconception that a third-party
-> > manufactured hardware token would magically infuse trust into the final
-> > result of a cryptographic calculation. As we know, trapdoors can be
easily
-> > inserted into the calculation of keys or signatures, arguably more
-> > stealthly in a hardware token with concealed and secret source code.
->
-> This misses the point entirely. I'm not suggesting that a hardware
-> is a magic bullet. I'm merely observing that suitably designed
-> hardware tokens (of which several are available) can solve the
-> implementation problems you were complaining about. In fact,
-> hardware is quite a common requirement in certain environments
-> for precisely that reason.
->
My point was that a protocol weakness cannot be solved by hardware, no
matter how controlled.
Yes, but a lot of the things you were complaining about (e.g.
bad randomness for key generation, programs which are willing
to give up the key, etc.) are (1) not protocol bugs but
implementation bugs and (2) can be fixed by trusted hardware.
That was my only point.
-> That said, the issue of trapdoors is a red herring. Ultimately
-> you have to trust your vendor not to intentionally compromise your
-> security--or do it all yourself. Read "Reflections On Trusting Trust"
-> for an example that makes this point quite clearly.
First, "not intentionally compromised" is difficult to disprove,
especially when you bear the burden of proof in a tamper-proof device, no?
(Further, as you may remember from the case of Stac vs Microsoft, Stac
proved by reverse assembly of MS's code that DoubleSpace used substantial
code from Stac, but Stac was also found guilty of "invading" MS's code.)
Second, as above, no vendors or third-parties can be trusted in today's
competitive environment-- not even Volkswagen vis-a-vis General Motors.
What the international Internet community needs is not some immaterial
trust on a foreign government or company or, even, on a domestic
government or company -- but open knowledge and fail-safe procedures.
After all, if trust would be such a safe "blank check" then the whole
issue of key-escrow, TTP legislation and CAs would be moot.
I think you're missing the point here. The vast majority of users
of security critical software are using software supplied by
others, even if those others are in-house. If those suppliers can't
be trusted not to intentionally compromise your security, there
are very few measures that you can take to really protect yourself.
BTW, "Trusting Trust" reflects the wrong assumption that trust is
transitive -- which it is not.
From this, I infer that you haven't actually read "Reflections on
Trusting Trust", but are just guessing what it's about based
on the title. Am I right?
Certainly your comments don't speak at all to the point that the
paper is trying to make. (Hint: It's not about cryptography at
all.)
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."