encryption for the masses
From: those who know me have no need of my name (not-a-real-address@usa.net)Date: 08/25/02
- Next message: Dolphy: "Re: encryption for the masses"
- Previous message: Alexander Lysenko: "analysis security in win2000"
- Next in thread: Dolphy: "Re: encryption for the masses"
- Reply: Dolphy: "Re: encryption for the masses"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: those who know me have no need of my name <not-a-real-address@usa.net> Date: 25 Aug 2002 17:58:45 GMT
my response will probably sound like i am a proponent of s/mime over pgp.
which in fact i am not. but i don't find s/mime to be the hell hole that
many claim of it, but i do not find pgp to be a total solution either. as
such i have set followup's to comp.security.misc.
in alt.security.pgp i read:
>Most of the advice I read about plugins suggests they ought not be used,
>and my experience leads me to agree. The plugin technology has to be
>improved in the host email programs; it cannot be remedied by GnuPG or
>PGP.
>PGP's stated goal is to increase the size of that body by making encryption
>a seamless, easy-to-use addition to the process of communicating by
>computer.
that's what their business plan says, but it's not relevant to anyone
outside of the money raising side of their business. even so, a company
like pgp inc, or other efforts such as those made for gnupg, by having
worked hard to force a plug-in / utility to operate may have the desired
effect, of causing the companies that develop e-mail software to add an api
that is effective, e.g., the plug-in api in messenger appears sufficient to
allow useful pgp support be added without any untoward side-effects or
overly cumbersome interfacing.
>Frankly, I don't believe it will be possible to make encryption a seamless,
>easy-to-use component of communication in the foreseeable future.
the current s/mime integration in outlook, outlook express and messenger is
seamless, and trivial to use. the complications are in beginning to use it
at all, a point you make later in your post. there is little that can be
done to move cryptography into the core of the e-mail infrastructure, at
least not with any rapidity. not alone because it's been 20 years since
the standards by which it operates were written (and which you do note),
but there remains significant disparity between the technological choices
and groups that support each, and they aren't compatible.
for an individual to begin using s/mime using any of these programs
(outlook, outlook express or messenger) is simple, and costs nothing but
the few minutes necessary to enroll in thawte's freemail program. the main
hurdle is in deciding that thawte is the ca one desires or that freemail is
the appropriate program. there are many providers and options to be
considered. and even with useful introductory material to help people
choose, it still requires the initial incentive to begin the process. i
would have thought this to be trivial, given that signed or encrypted
communications would allow one to cope more easily with spam, but that
hasn't proven a sufficient motivator.
a company environment complicates some matters, yet simplifies others.
*if* you can get the company to decide that encryption, or at least
signing, is desirable then the user typically has no hurdles to jump, the
company does all the hard stuff. but that is still plenty, and may take
much longer to evaluate, especially the privacy angles about which the
individual might have strong opinion or the state may have regulations.
[if e-mail were to be encrypted all along]
>Then, there would have been no "plugins" to contend with.
i believe this to be incorrect, or at least i'd hope so. just because the
original developer provides an interface doesn't mean that they always did
a good job, or it may be that others would prefer that it work in some
different fashion. there is almost always a reason to have an api along
each major functional line, and not a small number of minor ones, though
there are often more than enough reasons that prevent their creation.
>suppose that some glaring weakness in [a crypto mechanism] is found--one
>so severe that an immediate switch to another [...] is required. By
>rights, you'd not want to receive sensitive email [using the compromised
>mechanism]. But that decision is not yours, it is the sender's. Until
>the sender's keyring has been updated with your new cipher preference,
>nothing stops from sending mail which is now completely insecure.
what would you do to repair this problem? would you replace it with some
sort of pre-message exchange, whereby the receiver could dynamically
approve or deny the message based on the intended metrics? what happens
when everything is fine but the recipient isn't available? what happens
when there are multiple recipients? what if the pre-message exchange is
the mechanism that is compromised?
the practical solution is that (sub)keys should expire, in a period that is
appropriate to the security desired. probably not years, and certainly not
`never' as is all too common an expiration used today (in pgp keys at
least, s/mime keys almost always expire yearly).
>And what about PKI? Look at the logistics problems if everyone on the
>planet were using crypto in email.
it is difficult to see what logistics problems one faces with pki that
aren't also present in the pgp `web of trust', or that would be missing
from any other system. with pki the central revocation list needs to be
consulted, to determine if the owner, authority or trusted third party has
revoked the key before it's natural demise, but one should periodically
validate pgp keys as well, so this not all that different.
in fact, ask yourself if the pgp system does the right thing now: what
happens if you accept a key based on it being signed by 1 other trusted
introducer (a too small number, but it's sufficient to raise this point),
but the introducer's key is then revoked? without communicating with
introducer to determine why the key was revoked you may have a key on your
ring that has trust it should not.
s/mime has problems as well. but integration into the main e-mail programs
is not one of them.
-- bringing you boring signatures for 17 years
- Next message: Dolphy: "Re: encryption for the masses"
- Previous message: Alexander Lysenko: "analysis security in win2000"
- Next in thread: Dolphy: "Re: encryption for the masses"
- Reply: Dolphy: "Re: encryption for the masses"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
