Are ++ and -- operators really more efficient

[CBFalconer]

.... snip ...


You're obviously not even close to being a cryptographer. For a
start, a CRC such as you suggest is unkeyed -- there's nothing
tying the author to the message: anyone can modify the message (or
just generate a new one) and compute the right CRC. Secondly,
there's no asymmetry here, so anyone who can verify the CRC can
generate a new one. Finally, CRCs are linear, so under some
circumstances you can work out how to modify the CRC and message
to construct a forgery without actually knowing either.

True. So what? There is no need for absolute security, just a
desire to reduce the incidence of message-fakers output being
accepted.

 

[Keith Thompson]

True. So what? There is no need for absolute security, just a
desire to reduce the incidence of message-fakers output being
accepted.

A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a genuine
message. It might help detect transmission errors, but I'm not aware
that that's been a problem.

 

[CBFalconer]

A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a genuine
message. It might help detect transmission errors, but I'm not aware
that that's been a problem.

Alright, so it's a bit lame. So improve it. It should not be
necessary to send anything bigger than a 16 to 32 bit value for
some form of checking. That would avoid those horrible expanses of
check codes, which are virtually always ignored anyhow.

 

[Keith Thompson]

Keith Thompson wrote: [...]

A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a genuine
message. It might help detect transmission errors, but I'm not aware
that that's been a problem.

Alright, so it's a bit lame. So improve it. It should not be
necessary to send anything bigger than a 16 to 32 bit value for
some form of checking. That would avoid those horrible expanses of
check codes, which are virtually always ignored anyhow.

You'll have to provide more details. Any kind of checksum that's
based only on the content of the article is useless; a forger can
generate it as easily as a legitimate poster. To be useful, it has to
be usable to *prove*, to a reasonably high degree of confidence, that
a given article was actually posted by a specific person. The only
way I can think of to do that is some kind of public-key cryptography.
I suppose you could do something similar to PGP but with a smaller key
and a smaller signature, but I can't think of anything that would be a
qualititative improvement (i.e., doing something more than just making
the code block a few lines shorter).

If you can describe a way to generate a 32-bit check value that can
verify the identify of the poster, please enlighten me.

 

[CBFalconer]

Keith Thompson wrote: [...]

A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a
genuine message. It might help detect transmission errors, but
I'm not aware that that's been a problem.

Alright, so it's a bit lame. So improve it. It should not be
necessary to send anything bigger than a 16 to 32 bit value for
some form of checking. That would avoid those horrible expanses
of check codes, which are virtually always ignored anyhow.

You'll have to provide more details. Any kind of checksum that's
based only on the content of the article is useless; a forger can
generate it as easily as a legitimate poster. To be useful, it
has to be usable to *prove*, to a reasonably high degree of
confidence, that a given article was actually posted by a specific
person. The only way I can think of to do that is some kind of
public-key cryptography. I suppose you could do something similar
to PGP but with a smaller key and a smaller signature, but I can't
think of anything that would be a qualititative improvement (i.e.,
doing something more than just making the code block a few lines
shorter).

If you can describe a way to generate a 32-bit check value that
can verify the identify of the poster, please enlighten me.

Bringing it down to one line would do. As you pointed out, I am
not any form of cryptographer. But my instinct tells me something
is available. What about - take the crc (maybe a 32 or 64 bit one)
and encode that with a private key. Send the message with an
X-header, specifying the public key. So the receiver decodes the
crc, runs a crc generator on the content, and compares. Without
the private key that is hard to duplicate, which is all that is
needed. The decoding is short, thus fast. The crc generator is
fast. Instantaneous confirmation.

I am just generating some ideas. I am not especially interested in
the result; I just want to eliminate the monstrous additions to
messages. Let somebody else work it out.

 

[Stephen Sprunk]

Bringing it down to one line would do. As you pointed out, I am
not any form of cryptographer. But my instinct tells me something
is available. What about - take the crc (maybe a 32 or 64 bit one)
and encode that with a private key. Send the message with an
X-header, specifying the public key. So the receiver decodes the
crc, runs a crc generator on the content, and compares. Without
the private key that is hard to duplicate, which is all that is
needed. The decoding is short, thus fast. The crc generator is
fast. Instantaneous confirmation.

I am just generating some ideas. I am not especially interested in
the result; I just want to eliminate the monstrous additions to
messages. Let somebody else work it out.

In fact, you're not far off from the best known solution: hash the data
with a secure algorithm like SHA1 (not a weak one like CRC), sign the
result with your private key, and include the public key in the message
with the signature.

The problem is that, to do it right, the amount of information required
is far more significant than you seem to expect. While the signature
itself will be fairly small (e.g. the size of the hash's output, 160
bits for the case of SHA1), public key certificates are not. The
signature in the sample signed message I sent a few hours ago in this
thread comes out to 2175 bytes before base64 encoding -- and most of
that is the public key and the signature by the issuing CA. Without
those, a random receiver cannot validate the (relatively small) message
signature, which is the entire point. If you know who the parties are
prior to receiving the message, that information only has to be
exchanged once, but that does not apply on USENET (or in email, in most
cases) so the overhead has to be added to every message for the system
to be usable. There is provably no shortcut.

I suspect that your main problem with PGP is not actually the size but
that it includes all this cruft in the message body itself, where it
assaults the eyes. S/MIME uses the same (strong) high-level design as
PGP, but the signature and public key certificate are not in the message
body and thus can be easily ignored by news (or mail) readers that
aren't interested in them. MIME has been around long enough that
virtually all software understands it, even if many programs still don't
understand S/MIME signatures or what to do with them.

S

 

[Keith Thompson]

Keith Thompson wrote: [...]
A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a
genuine message. It might help detect transmission errors, but
I'm not aware that that's been a problem.

Alright, so it's a bit lame. So improve it. It should not be
necessary to send anything bigger than a 16 to 32 bit value for
some form of checking. That would avoid those horrible expanses
of check codes, which are virtually always ignored anyhow.

You'll have to provide more details. Any kind of checksum that's
based only on the content of the article is useless; a forger can
generate it as easily as a legitimate poster. To be useful, it
has to be usable to *prove*, to a reasonably high degree of
confidence, that a given article was actually posted by a specific
person. The only way I can think of to do that is some kind of
public-key cryptography. I suppose you could do something similar
to PGP but with a smaller key and a smaller signature, but I can't
think of anything that would be a qualititative improvement (i.e.,
doing something more than just making the code block a few lines
shorter).

If you can describe a way to generate a 32-bit check value that
can verify the identify of the poster, please enlighten me.

Bringing it down to one line would do. As you pointed out, I am
not any form of cryptographer. But my instinct tells me something
is available. What about - take the crc (maybe a 32 or 64 bit one)
and encode that with a private key. Send the message with an
X-header, specifying the public key. So the receiver decodes the
crc, runs a crc generator on the content, and compares. Without
the private key that is hard to duplicate, which is all that is
needed. The decoding is short, thus fast. The crc generator is
fast. Instantaneous confirmation.

PGP confirmation is close enough to instantaneous that making it
faster (and less reliable) doesn't buy you much -- and the
infrastructure for PGP already exists.

[...]

I am just generating some ideas. I am not especially interested in
the result; I just want to eliminate the monstrous additions to
messages. Let somebody else work it out.

Anyone who feels the need to cryptographically sign Usenet postings
isn't likely to accept a weaker alternative method. The trick is to
realize that going without a cryptographic signature isn't a real
problem.

There might be a lightweight and reliable solution waiting to be
developed -- but I'll bet it won't be the result of a discussion in
comp.lang.c.

 

[Richard]

Keith Thompson wrote: [...]
A 16-bit CRC provides *no* security against deliberate forgeries.
It's as easy to generate a correct CRC for a forgery as for a
genuine message. It might help detect transmission errors, but
I'm not aware that that's been a problem.

Alright, so it's a bit lame. So improve it. It should not be
necessary to send anything bigger than a 16 to 32 bit value for
some form of checking. That would avoid those horrible expanses
of check codes, which are virtually always ignored anyhow.

You'll have to provide more details. Any kind of checksum that's
based only on the content of the article is useless; a forger can
generate it as easily as a legitimate poster. To be useful, it
has to be usable to *prove*, to a reasonably high degree of
confidence, that a given article was actually posted by a specific
person. The only way I can think of to do that is some kind of
public-key cryptography. I suppose you could do something similar
to PGP but with a smaller key and a smaller signature, but I can't
think of anything that would be a qualititative improvement (i.e.,
doing something more than just making the code block a few lines
shorter).

If you can describe a way to generate a 32-bit check value that
can verify the identify of the poster, please enlighten me.

Bringing it down to one line would do. As you pointed out, I am
not any form of cryptographer. But my instinct tells me something
is available. What about - take the crc (maybe a 32 or 64 bit one)
and encode that with a private key. Send the message with an
X-header, specifying the public key. So the receiver decodes the
crc, runs a crc generator on the content, and compares. Without
the private key that is hard to duplicate, which is all that is
needed. The decoding is short, thus fast. The crc generator is
fast. Instantaneous confirmation.

I am just generating some ideas. I am not especially interested in
the result; I just want to eliminate the monstrous additions to
messages. Let somebody else work it out.

Serious question : what the hell are you talking about? Learn to set
your system up properly.

While I think only pretentious fools sign their usenet posts, any half
decent news reader should be able to hide the crap signed posts come
with.

And how come this is suddenly "on topic"? Make up your mind.

 

[Mark Wooding]

The problem is that, to do it right, the amount of information
required is far more significant than you seem to expect. While the
signature itself will be fairly small (e.g. the size of the hash's
output, 160 bits for the case of SHA1), public key certificates are
not.

But there's no need to send the certificate. An indication of the right
key is sufficient -- and that needn't be any longer than a tinyurl
suffix (i.e., without the `http://tinyurl.com/' on the front).

Someone interested in verifying the signature can download the public
key and certificate, check that, and then verify the signature. (Note
that this doesn't mean we need to trust TinyURL to be honest. Public
key certificates are `self authenticating': you can tell you've got the
right one when you see it.)

S/MIME just spams everyone with pointless copies of the public key and
certificate for no good reason.

If you know who the parties are prior to receiving the message, that
information only has to be exchanged once, but that does not apply on
USENET (or in email, in most cases) so the overhead has to be added to
every message for the system to be usable.

Absolute rubbish. Almost everyone reading news or email can also fetch
stuff from web servers. So you don't need to send certificates at all.

There is provably no shortcut.

.... Except that PGP actually /doesn't/ send a certificate with every
signature, which proves that this claim is false.

The signature data contains the signature itself (which with DSA is 40
bytes) a 64-bit key-ID, a datestamp, and a few bytes of metadata
(lengths, algorithm identifiers, that sort of thing). No certificate.
If you care, you're expected to download the public key and its
certificates from a keyserver; the key-ID contains the information
necessary to do this. A PGP signature can therefore be as short as
this:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJduzzBZyfGnpkR18RAg72AKDDlo7SAgY+XMzNcWPQOXmHNK5f/ACdG6+v
K2lHnKXmAK5D/1Ti5HHFr5I=
=BmXu
-----END PGP SIGNATURE-----

(I'm not telling you the message.) I think that's still too long and
ugly.

I suspect that your main problem with PGP is not actually the size but
that it includes all this cruft in the message body itself, where it
assaults the eyes.

PGP/MIME can stash the signature in a separate MIME part of the message.
My newsreader at least can cope with this just fine. But people with
old-fashioned newsreaders will see all the horrid MIME multipart stuff
as well as the signature.

S/MIME uses the same (strong) high-level design as PGP,

That's very debatable. I'd say that S/MIME's certification model is
fundamentally flawed, but that's an argument to take to sci.crypt.

but the signature and public key certificate are not in the message
body and thus can be easily ignored by news (or mail) readers that
aren't interested in them. MIME has been around long enough that
virtually all software understands it, even if many programs still
don't understand S/MIME signatures or what to do with them.

Well, current trn4 looks like it recognizes MIME (which trn3 doesn't at
all) but still shows you some cruft.

-- [mdw], posting in Gnus, which handles all of this stuff by magic.

 

[Mark Wooding]

PGP, however, requires embedding the signature (not a "check code") in
the message body, which would require modifying every email client and
news reader on the planet to recognize (and hide) all the non-standard
cruft it adds to messages.

Rubbish. RFC2015 and RFC3156 have existed since 1996 and 2001
respectively.

-- [mdw]

 

[Keith Thompson]

But there's no need to send the certificate. An indication of the right
key is sufficient -- and that needn't be any longer than a tinyurl
suffix (i.e., without the `http://tinyurl.com/' on the front).

[...]

But you still need a way to verify that it's the right key.
If I want to forge a message so that it appears to be from
you, I can trivially generate a PGP key for "Mark Wooding
<[email protected]>", upload it to the servers, and use it to
sign my forgeries. PGP attempts to solve this with key servers and
a "web of trust", while other methods use a top-down approach with
trusted certificate authorities. So far, neither method is
implemented with enough transparency for the end user for me
to bother using it for Usenet postings.

 

[Nate Eldredge]

But there's no need to send the certificate. An indication of the right
key is sufficient -- and that needn't be any longer than a tinyurl
suffix (i.e., without the `http://tinyurl.com/' on the front).

[...]

But you still need a way to verify that it's the right key.
If I want to forge a message so that it appears to be from
you, I can trivially generate a PGP key for "Mark Wooding
<[email protected]>", upload it to the servers, and use it to
sign my forgeries. PGP attempts to solve this with key servers and
a "web of trust", while other methods use a top-down approach with
trusted certificate authorities. So far, neither method is
implemented with enough transparency for the end user for me
to bother using it for Usenet postings.

But on the other hand, for Usenet, the purpose of having one's name on a
post isn't so much to identify the author personally, as to associate
the post it with the author's previous posts. If Frances Foobar has a
history of accurate and well-thought-out posts, then putting her name on
a new post adds credibility to it, and helps make it more likely that
someone will read it. It also allows a longtime reader to recall what
she knows about Frances' interests, opinions, and biases, to understand
the post in context. Indeed, the name itself is irrelevant; posters can
certainly establish this kind of reputation under a pseudonym. The
danger of forgery is mainly that it sullies the victim's Usenet
reputation, more than its effect on the victim's real-life reputation.

So for this purpose, what's important to certify is not "this article
was written by the real-life woman named Frances Foobar" but "this
article was written by the same person as all these others". So Frances
could maintain, on a web site somewhere, a list of all her posts, and
have each post include a link to that site (which could be very short).
If she likes, the list can include detached cryptographic signatures all
generated with the same key. A forgery can be identified because it
won't appear on that list; indeed, Frances could have a list of posts
which she specifically disavows.

The only disadvantage of this (that I can see) compared to having the
signature in the post is that it makes it easier for Frances to later
disavow a genuine post if she comes to regret it, by removing it from
the list. Of course, in either case she can avoid authenticating the
post when she makes it, if it's something she knows she doesn't want
associated with her Usenet persona; there's no way to avoid sock
puppetry.

 

[Ben Bacarisse]

But there's no need to send the certificate. An indication of the right
key is sufficient -- and that needn't be any longer than a tinyurl
suffix (i.e., without the `http://tinyurl.com/' on the front).

[...]

But you still need a way to verify that it's the right key.
If I want to forge a message so that it appears to be from
you, I can trivially generate a PGP key for "Mark Wooding
<[email protected]>", upload it to the servers, and use it to
sign my forgeries. PGP attempts to solve this with key servers and
a "web of trust", while other methods use a top-down approach with
trusted certificate authorities. So far, neither method is
implemented with enough transparency for the end user for me
to bother using it for Usenet postings.

That's true, but to large extent it does not matter on Usenet. A key
-- even an untrusted one -- does link a set of messages together as
being from the same person (or, at last, from some set of people who
have access to the same private key).

I don't really mind if you are or are not really called Keith
Thompson. I read your posts carefully because I have come to learn
that they are almost always reliable and to the point, but at the
moment that trust is build solely on the assumption that everything
that seems to be by you is by the same person. PGP signed messages
would enable trust to be built up and associated with unforgeable
identities.

It is ironic to me that PGP signatures are so derided on Usenet when
in fact they would be more useful to me here than in emails.

 

[Stephen Sprunk]

Rubbish. RFC2015 and RFC3156 have existed since 1996 and 2001
respectively.

And how many people use them, versus dumping all the cruft in the
message body?

S

 

[Stephen Sprunk]

But there's no need to send the certificate. An indication of the right
key is sufficient -- and that needn't be any longer than a tinyurl
suffix (i.e., without the `http://tinyurl.com/' on the front).

.... which means that the recipient must have web access (not guaranteed)
and that the certificate must be kept available (at the same URL) for as
long as anyone could possibly want to verify the message.

Someone interested in verifying the signature can download the public
key and certificate, check that, and then verify the signature. (Note
that this doesn't mean we need to trust TinyURL to be honest. Public
key certificates are `self authenticating': you can tell you've got the
right one when you see it.)

Correct, subject to the above assumptions. If those assumptions do not
hold, the entire scheme breaks down.

S/MIME just spams everyone with pointless copies of the public key and
certificate for no good reason.

They are not pointless; it is _your_ opinion that the reason is not
good, but "good" or "bad" is entirely subjective.

Absolute rubbish. Almost everyone reading news or email can also fetch
stuff from web servers. So you don't need to send certificates at all.

"Almost everyone" is not good enough for those of us who wish to
communicate securely with people who do not have unfettered web access
24x7. For instance, I read a significant amount of mail and news while
"offline" on planes and such. Many folks in remote locations _still_
have dialup or wireless services and send/receive their mail and news in
batches. Windows users sitting at home with always-on DSL access are
not the entire world...

... Except that PGP actually /doesn't/ send a certificate with every
signature, which proves that this claim is false.

The signature data contains the signature itself (which with DSA is 40
bytes) a 64-bit key-ID, a datestamp, and a few bytes of metadata
(lengths, algorithm identifiers, that sort of thing). No certificate.
If you care, you're expected to download the public key and its
certificates from a keyserver; the key-ID contains the information
necessary to do this. A PGP signature can therefore be as short as
this:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJduzzBZyfGnpkR18RAg72AKDDlo7SAgY+XMzNcWPQOXmHNK5f/ACdG6+v
K2lHnKXmAK5D/1Ti5HHFr5I=
=BmXu
-----END PGP SIGNATURE-----

Ah. Last time I used PGP, it didn't have the option to _not_ include
the certificate, but that was back before "keyservers" existed and there
was no other effective solution. Even today, most people do in fact
send the certificate.

I'd bet that if I looked hard enough, there's an option to do the same
for S/MIME. However, the only complaint I've _ever_ gotten about my
signing emails is that the recipient's program automatically wants to
sign the response and asks for their key's passphrase.

(I'm not telling you the message.) I think that's still too long and
ugly.

Agreed. The start/version/end markers are still excessive; if it were
just the actual encoded signature, that'd be acceptable.

PGP/MIME can stash the signature in a separate MIME part of the message.
My newsreader at least can cope with this just fine. But people with
old-fashioned newsreaders will see all the horrid MIME multipart stuff
as well as the signature.

I have no pity on folks using software that does not understand MIME; it
was first standardized in 1993 and many programs supported it even earlier.

That's very debatable. I'd say that S/MIME's certification model is
fundamentally flawed, but that's an argument to take to sci.crypt.

That's a problem with X.509 certificates and the PKI model commonly used
with them; the high-level design of S/MIME (securely hash the message,
sign it with a private key, etc.) is the same as PGP.

Well, current trn4 looks like it recognizes MIME (which trn3 doesn't at
all) but still shows you some cruft.

I'm curious what "cruft" it shows you for my signed example message; my
newsreader just puts a little icon in the header bar that shows the
message has a valid signature. Even a non-S/MIME-capable reader should
just show it as an attachment, rather than adding cruft to the message body.

-- [mdw], posting in Gnus, which handles all of this stuff by magic.

S, posting in Thunderbird, which handles S/MIME by magic but requires a
plug-in for PGP

 

[CBFalconer]

.... snip ...

It is ironic to me that PGP signatures are so derided on Usenet
when in fact they would be more useful to me here than in emails.

They wouldn't be if they were short (1 line) or hidden (in
headers). Hiding is generally awkward, because the medium is text,
and you can't insist on funny formats, such as html.

 

[CBFalconer]

Mark Wooding wrote:
.... snip ...


I have no pity on folks using software that does not understand
MIME; it was first standardized in 1993 and many programs
supported it even earlier.

I do. Usenet is text file based. It is usable on very primitive
mechanisms. It works very nicely on those (and other) mechanisms.

 

[Stephen Sprunk]

I do. Usenet is text file based. It is usable on very primitive
mechanisms. It works very nicely on those (and other) mechanisms.

News uses the _exact_ same format as mail, with only a few minor
differences in the headers. MIME works equally well with both, despite
the "Mail" in the name. Attachments are unwelcome in most groups
outside alt.binaries, and HTML messages (which are, in fact, "text
files") are considered rude, but there are many other things that MIME
does -- like allowing the use of non-ASCII characters in messages.

S

 

[Mark Wooding]

But you still need a way to verify that it's the right key. If I want
to forge a message so that it appears to be from you, I can trivially
generate a PGP key for "Mark Wooding <[email protected]>", upload
it to the servers, and use it to sign my forgeries.

You've misunderstood my point. Consider an alternate world where S/MIME
was designed slightly differently. Rather than containing the public
key certificate chain directly, the signature contains a URL indicating
where the certificate can be found. This is a simple indirection step.
Clients verifying signatures need to fetch the certificate in order to
be able to display the signer's identity; clients might maintain a
cache, or simply rely on a caching web proxy. (It'll a plain HTTP URL:
there's no need for heavyweight HTTPS here.)

What can an adversary do to this scheme that he can't do to current
S/MIME? Well, he can impersonate the HTTP server, e.g., by DNS
poisoning or something; or he can just swap the URL for a different one.
Either way, he gets to substitute a different certificate. But this
isn't different from S/MIME, where he could just swap the certificate in
the signature.

Besides, in fact none of this really matters. `Keith Thompson', to me,
is nothing but a label I have for a source of wisdom on matters of C.
If you sign your articles (and I care to verify them -- which, as a
matter of course, I don't) then what I really care about is that your
/public key/ denotes a source of C wisdom. Public keys are long and
hard to remember, but I can give them nicknames -- maybe I'd call it
`Keith Thompson'. (This idea that public keys represent principals --
rather than attempting to introduce an indirection layer between public
keys and real-world identities -- underlies the SPKI/SDSI system.)

Finally, there's another problem which signatures just don't address. I
could, quite easily, start (re-)signing your messages using my key (with
a sock-puppet name attached). There's no particularly interesting
change here -- the credit which should have gone to `Keith Thompson' now
goes to `mdw's sock puppet', but this is a trivial renaming. But I can
do worse: I could also (re-)sign messages from (say) Han from China
(maybe editing them slightly). Now everyone who gets messages through
me (could be quite a lot of people, if I play stupid games with cancel
messages and so on) thinks that their previously reliable source has
become a ghastly troll.

It's a bit far-fetched. But it's still vaguely possible, and there just
isn't any crypto you can use to stop it. Sorry.

-- [mdw]

 

[Mark Wooding]

[This subthread is becoming increasingly off-topic for comp.lang.c.
Does anyone have objections to moving it to sci.crypt? I'd do it
unilaterally, but I don't want to leave out people who have incomplete
feeds.]

... which means that the recipient must have web access (not
guaranteed) and that the certificate must be kept available (at the
same URL) for as long as anyone could possibly want to verify the
message.

Yes. The latter's not difficult to arrange. CAs could provide download
services for their customers (and actually earn the money they make).
How come you're receiving email or news but don't have a net connection?

More importantly, why do you think it's important to verify that a
(particular, named) someone you've never heard of and are never likely
to meet signed a particular message? If you actually have an /a priori/
relationship with someone, you ought to have a means of obtaining a
certificate in advance. If you don't, you might as well be establishing
a very authentic channel with the adversary.

They are not pointless; it is _your_ opinion that the reason is not
good, but "good" or "bad" is entirely subjective.

No. I've given justifications for my claims, and I'm continuing to do
so.

"Almost everyone" is not good enough for those of us who wish to
communicate securely with people who do not have unfettered web access
24x7. For instance, I read a significant amount of mail and news
while "offline" on planes and such. Many folks in remote locations
_still_ have dialup or wireless services and send/receive their mail
and news in batches. Windows users sitting at home with always-on DSL
access are not the entire world...

Again, there is /no point/ in establishing secure communications with
someone you have no way of identifying. Here, by `identify', I mean
`match up with some other locally meaningful identifying characteristic'
rather than just coming up with a name. It's interesting to know that a
message was signed by your friend, by a representative of some company
you have or plan to have dealings with, by the author of a book or
paper, etc. It's not useful to know that your message was signed by
someone who might be called `Mark Wooding' or `Falcon Kirtaran' because
that doesn't give you any additional information about who the signer
actually /is/.

Ah. Last time I used PGP, it didn't have the option to _not_ include the
certificate

PGP has /never/ included the certificate in its signature. Never, ever,
ever.

but that was back before "keyservers" existed and there was no other
effective solution. Even today, most people do in fact send the
certificate.

Simply false. Many PGP signatures are larger than the one I posted
because they use RSA rather than DSA. This is the only difference.

(Some idiots think that posting their entire public PGP key, with all
the certificates attached, is a good idea. These people receive
justifiable complaints.) Back in the days before key-servers, people
used to provide their public keys through FTP, HTTP or finger (and even
now you can get mine by fingering (e-mail address removed), should you be
interested.)

I have no pity on folks using software that does not understand MIME;
it was first standardized in 1993 and many programs supported it even
earlier.

It was standardized for use in email. I'm not aware of an RFC
sanctioning the use of MIME in news articles. RFC1036 is not marked as
updated or obsoleted. Use in news took much longer, pushed largely by
graphical all-in-one-news/mail clients, and was fought quite vigorously.
I still don't think it's necessarily complete.

That's a problem with X.509 certificates and the PKI model commonly
used with them; the high-level design of S/MIME (securely hash the
message, sign it with a private key, etc.) is the same as PGP.

Oh -- to me, that's a cryptographic detail. The interesting design
stuff is in the key management, and that's where the two differ.

I'm curious what "cruft" it shows you for my signed example message;
my newsreader just puts a little icon in the header bar that shows the
message has a valid signature. Even a non-S/MIME-capable reader
should just show it as an attachment, rather than adding cruft to the
message body.

aptitude install trn2 inn2-inews ... start, find article, ...

It puts a `-=-=-=-=-=-' marker at the top (in standout), and a note

-=-=-=-=-=-
[Attachment type=application/x-pkcs7-signature, name=smime.p7s]
-=-=-=-=-=-

at the bottom (again the markers are in standout). It's certainly less
objectionable than the Kirtaran's PGP cruft (which trn4 shows in full!)
but it's still somewhat annoying. (Standout appears white-on-black,
which is visually distracting.)

-- [mdw]