| View previous topic :: View next topic |
| Author |
Message |
Doug Laidlaw
Guest
|
 Posted: Thu Nov 13, 2008 9:28 am Post subject: GPG |
 |
|
I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
Doug.
--
It is all right letting yourself go as long as you can let yourself back.
- Mick Jagger. |
|
| |
|
 Back to top |
s. keeling
Guest
|
| Posted: Fri Nov 14, 2008 1:05 am Post subject: Re: GPG |
|
|
Doug Laidlaw <doug@dougshost.invalid>:
| Quote: |
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
|
You can encrypt a file so that only your intended recipient can unlock
it. If subsequently it gets out into the open, you can blame them.
You can also crypto-sign (but not encrypt) it, proving it could only
have come from you. Many Usenetters find this very useful.
How about encrypted backups, so only you can recover them? So when
that courier loses them on the way to off-site storage, you're not up
on data retention charges, or Payment Card Industry (PCI) faults.
With the latest implementations, crypto has become far easier to use
than it once was. In many scenarios these days, it's very useful.
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://blinkynet.net/comp/uip5.html Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me. |
|
| |
|
| Back to top |
b.jeswine
Guest
|
| Posted: Fri Nov 14, 2008 2:09 am Post subject: Re: GPG |
|
|
"Doug Laidlaw" <doug@dougshost.invalid> wrote in message
news:fgjsu5-s0t.ln1@dougshost.douglaidlaw.net...
| Quote: | I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
|
Huh? First you say that you don't then you say that you do. Make up your
mind. |
|
| |
|
| Back to top |
Tim Greer
Guest
|
| Posted: Fri Nov 14, 2008 2:35 am Post subject: Re: GPG |
|
|
Doug Laidlaw wrote:
| Quote: | I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I
will never use, and locales that I will never use, with no better
justification than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I
can
see where it is worth the trouble is emailing credit card details. If
such
an email is signed with GPG, is it protected during transit? It is in
no way protected upon arrival.
Doug.
|
As with a lot of security ramifications and methods, etc., not everyone
needs them. PGP (GPG) is very useful to a lot of people. Sure,
emailing CC information is an excellent reason to use PGP encryption.
If it's signed with PGP, yes, it's protected in transit, at least in a
matter of speaking. If someone managed to obtain that data (assuming
you weren't using SSL/TLS for email transmission -- and that risk is
far lower than most anything else in this scenario), then they'd have a
PGP encrypted email that would have to break (good luck if you use a
good passkey/phrase).
Also, who is to say it wouldn't be protected upon arrival? Why not?
Who is physically at that system? After all, to be fair, all bets are
basically off if you don't have physical security for your system(s).
Still, who would be receiving such information, even if in a secure
location, with the PGP key auto-decrypting the email? You can simply
not add it and have it set to manually supply it to decrypt the email.
Then, what does someone have physically at the system? A PGP encrypted
email they probably can't do anything with. Same for PGP encrypted
data/files on the system itself (say a master password file, just for
example). PGP is good for a lot of uses, and I don't think it as a
"because it's there" type of thing. Though, that's not to say that you
personally will have a reason to use it, just that a lot of people do.
The fact you posted this question on this newsgroup leads me to believe
you probably do have some use, or know it is something useful.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle! |
|
| |
|
| Back to top |
Allen Kistler
Guest
|
| Posted: Fri Nov 14, 2008 7:26 am Post subject: Re: GPG |
|
|
Doug Laidlaw wrote:
| Quote: | I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
|
Several points:
The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
Signing your payment card info does not in any way "protect" it from
interception.
To protect the info in transit, you need the recipient's public key and
you need to use it to encrypt the data to him (and maybe to yourself so
you can read what you sent).
If you use a reliable method to transport information confidentially to
someone who's careless with the info after he gets it, then you should
make sure that he's contractually liable for negligence on his part. If
you can enforce no such liability on someone who's known to be
negligent, why are you sending him confidential information? That's not
a technical problem, and it's not going to have a technical solution. |
|
| |
|
| Back to top |
Hal Murray
Guest
|
| Posted: Fri Nov 14, 2008 8:21 am Post subject: Re: GPG |
|
|
| Quote: | The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
|
The "and has your public key" step is interesting.
How do you know that what you think is my public key is actally
my public key rather than something invented by a spammer trying
to steal my identiy?
--
These are my opinions, not necessarily my employer's. I hate spam. |
|
| |
|
| Back to top |
Nico Kadel-Garcia
Guest
|
| Posted: Fri Nov 14, 2008 3:39 pm Post subject: Re: GPG |
|
|
Doug Laidlaw wrote:
| Quote: | I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
Doug.
|
Slow up. GPG and its ancestor PGP are also used to authenticate things you've
received, such as software packages. This allows you to get the publicly
available public key for someone you'd like to trust, and test the received
software packages from them, and know that the transaction was sent by someone
who owns that key. This is similar to the SSL keys, but potentially better
because you don't rely on some central authority who may be completely
unworthy of trust. (Look up Palladium and Trusted Computing for the problems
of leaving a centralized private key repository in soomeone else's hands.)
So if you want to download and install software that comes from a software
mirror saying it's a RedHat RPM mirror, and the packages aren't signed with
the right key, you can be pretty sure the package didn't come from RedHat. And
yes, in transit where the NSA has been caught putting fiber-optic taps on
AT&T's network and where the Carnivore email text monitoring continues to run,
your important communications are at risk from both illicit government
authority and from script kiddies running packet sniffers.
The reason this kind of encryption is not used by default is not a technical
one, it's a legal one. Look at the history of the United States' regulations,
not laws, on the export of encryption. They've been ruled unconstitutional
before, and simply shifted to a different department, but they interfere with
promoting ubiquitous and robust end-to-end encryption. |
|
| |
|
| Back to top |
Doug Laidlaw
Guest
|
| Posted: Fri Nov 14, 2008 7:45 pm Post subject: Re: GPG |
|
|
Allen Kistler wrote:
| Quote: | Doug Laidlaw wrote:
I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I
will never use, and locales that I will never use, with no better
justification than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If
such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
Several points:
The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
Signing your payment card info does not in any way "protect" it from
interception.
To protect the info in transit, you need the recipient's public key and
you need to use it to encrypt the data to him (and maybe to yourself so
you can read what you sent).
If you use a reliable method to transport information confidentially to
someone who's careless with the info after he gets it, then you should
make sure that he's contractually liable for negligence on his part. If
you can enforce no such liability on someone who's known to be
negligent, why are you sending him confidential information? That's not
a technical problem, and it's not going to have a technical solution.
|
The whole thing of interception is interesting. Here is a parallel from my
working life:
I was a lawyer/attorney. We have a split profession. I was called a
solicitor. We got the case ready for Court, and we got barristers to go to
Court for us. Barrister were not allowed to work in partnership, but they
were all in one building, and often shared fax machines, which stood out in
the lobby. We would send a fax to our barrister, and until he picked it
up, it was visible for all the world, and perhaps the opposition barrister,
to see. An insurance practice note pointed that out. Our barristers have
high ethical standards, and the opposition might be forced to withdraw from
the case, if he didn't realise until too late, what he was looking at. (I
once had to send papers to a barrister in the country. His clerk sealed
them up and gave them to the opposition barrister, who was just about to
leave to go there. That is how high the level of trust was. We have
lawyers too, of the kind who give them a bad reputation, but that has been
the case since the New Testament, probably earlier. The very system of
legal practice generates the idea, but that is another story.) If instead,
he used the info, I might become liable for negligence. Business efficiency
has to defer to that.
I don't fully understand GPG/PGP, but I get the point about the public key.
Hal queried it. As I understand it, I sign the message with the
recipient's public key (if he has one,) and that is like putting on it a
padlock to which only he has "the key." Only he can unlock it. I just
wonder about email sent to mailing lists which is signed with the sender's
key. Unless that protects it in transit, it is only proof of authenticity,
which isn't important on a public list, but may be good as a general
practice.
Doug.
--
How wonderful it is that nobody need wait a single moment before starting to
improve the world.
- Anne Frank. |
|
| |
|
| Back to top |
1PW
Guest
|
| Posted: Fri Nov 14, 2008 9:49 pm Post subject: Re: GPG |
|
|
On 11/14/2008 12:15 AM, Hal Murray sent:
| Quote: | The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
The "and has your public key" step is interesting.
How do you know that what you think is my public key is actually
my public key rather than something invented by a spammer trying
to steal my identity?
|
<http://en.wikipedia.org/wiki/Web_of_trust>
Bolster the Web of Trust by communicating using an alternate method.
The prospective sender verifies your key's validity through an alternate
channel of communications such as a phone call.
--
1PW
@?6A62?FEH9:DE=6o2@=]4@> [r4o7t] |
|
| |
|
| Back to top |
s. keeling
Guest
|
| Posted: Sat Nov 15, 2008 1:06 am Post subject: Re: GPG |
|
|
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net>:
| Quote: |
The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
The "and has your public key" step is interesting.
How do you know that what you think is my public key is actally
my public key rather than something invented by a spammer trying
to steal my identity?
|
My public key is mentioned in my headers, and it's uploaded to
keyservers to be publically available.
I don't use crypto much, but I strongly believe everyone should learn
to use it. It's a social skill.
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://blinkynet.net/comp/uip5.html Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me. |
|
| |
|
| Back to top |
1PW
Guest
|
| Posted: Sat Nov 15, 2008 4:00 pm Post subject: Re: GPG |
|
|
On 11/14/2008 05:45 AM, Doug Laidlaw sent:
Snip, snip...
(I
| Quote: | once had to send papers to a barrister in the country. His clerk sealed
them up and gave them to the opposition barrister, who was just about to
leave to go there. That is how high the level of trust was.
|
How refreshing! What an honor that must have been!
| Quote: | I don't fully understand GPG/PGP, but I get the point about the public key.
Hal queried it. As I understand it, I sign the message with the
recipient's public key (if he has one,) and that is like putting on it a
padlock to which only he has "the key." Only he can unlock it. I just
wonder about email sent to mailing lists which is signed with the sender's
key. Unless that protects it in transit, it is only proof of authenticity,
which isn't important on a public list, but may be good as a general
practice.
Doug.
|
Hello Doug:
I slight misunderstanding may exist in your description above. In many
examples, the fictitious characters Alice, and Bob are used.
It is assumed that Alice and Bob both have the capability of dealing
with a PGP or GPG messages. Also, each has generated secret and public
keys and they have exchanged validated public keys with each other.
1.) Alice has several modes of transmission available to her. Alice
may send her plaintext to Bob /without/ PGP/GPG, but, Bob can not be
absolutely certain that the message is from Alice, nor can he be sure
that the message hasn't been altered by a "man in the middle" attack.
2.) Alice may send her plaintext to Bob with the help of PGP/GPG and
only PGP/GPG "sign" the message. If Bob optionally uses his PGP/GPG to
validate the email, he has a high degree of confidence that the message
is from Alice *AND* that the plaintext has *NOT* been altered. The man
in the middle might still know the content because the message might
still be in a readable form during transmission.
3.) Alice may encrypt/sign her text, so that it becomes a cyphertext,
using Bob's public key. In a practical sense, only Bob may decrypt the
email back into plaintext with his PGP/GPG. Bob may be quite certain
that the email came from Alice. The man in the middle's only possible
interference /might/ be to intercept the message from Alice on the way
to Bob and prevent it from reaching Bob. However, the man in the middle
would not reasonably ever me able to know the deciphered content of the
email.
I hope this better explains the several modes that are available to all
of us.
Best wishes to you.
Pete
--
1PW
@?6A62?FEH9:DE=6o2@=]4@> [r4o7t] |
|
| |
|
| Back to top |
Daniel James
Guest
|
| Posted: Sat Nov 15, 2008 8:20 pm Post subject: Re: GPG |
|
|
In article news:<gfm6jh$va9$1@news.motzarella.org>, 1Pw wrote:
| Quote: | 3.) Alice may encrypt/sign her text, so that it becomes a cyphertext,
using Bob's public key. In a practical sense, only Bob may decrypt
the email back into plaintext with his PGP/GPG. Bob may be quite
certain that the email came from Alice. The man in the middle's
only possible interference /might/ be to intercept the message from
Alice on the way to Bob and prevent it from reaching Bob. However,
the man in the middle would not reasonably ever me able to know the
deciphered content of the email.
|
Not quite ...
Alice may encrypt the message with Bob's public key, she may sign the
message with her own private key, or neither, or both. She cannot sign
with Bob's key, and her encrypting with Bob's key does not allow Bob to
determine that the message came from Alice.
Encrypting the message with Bob's public key ensures that only Bob --
the only holder of Bob's private key can read the message. This assumes
that Bob has taken adequate measures to ensure that nobody else has
learned his private key and that the entire GPG cryptosystem hasn't been
broken in some way (such as a breakthrough in the mathematics behind it
or the discovery of a serious bug in the code) -- but in general these
things may safely be assumed.
Note that Bob's public key is, in general, known to many people so the
fact that Alice has chosen to encrypt the message does not in any way
guarantee that Alice is the sender. Alice must, however, be sure that
the key she uses does indeed belong to Bob, and not some eavesdropper
(who is conventionally referred to as "Eve") otherwise it will be the
eavesdropper (and not Bob) who can decrypt the message.
In signing the message Alice does not in any way alter or obscure the
content of the message, she merely appends a digital signature -- a
block of data that depends on the content of the message and on the
value of Alice's private key. Annyone who receives the message can read
it, and anyone who has Alice's public key can verify that the message
has not been altered in any way, and that Alice was indeed the sender.
In general Alice's public key is well-known, so anyone can verify these
things. Note that having the ability to verify the signature does not
imply having the ability to alter the message and re-create it. A
private key and its corresponding public key are a complementary pair,
and neither can be used to perform the tasks of the other.
Not that for this to be meaningful Bob must be quite sure that the key
he believes to be Alice's is genuine. If there is any possibility that
some other party -- Eve, say -- has published a bogus key in Alice's
name and tricked Bob into believing that the bogus key is the correct
one then it will be possible for Eve to alter Alice's message, sign it
with the bogus key, and pass it on to Bob to whom it will appear
genuine.
PGP/GPG has mechanisms to allow the user to attach a "level of trust" to
every other user's public key held on his keyring. If Bob has received
Alice's key directly from Alice then he will presumably trust it
absolutely, if he has received it from some other person whom he
personally knows he will possibly trust it only a little less (because
he cannot be quite so certain of the key's provenance), but if he has
received it via a casual acquaintance or colleague he will trust it much
less. If he receives the key directly in an unsecured EMail from Alice,
whom he has never met, he should not trust it at all, because the EMail
might actually be from Eve.
This PGP key management scheme works well among relatively limited
groups of which all the members know at least some of the others, so
that a ring of trust can be established.
In the more general case, where Alice and Bob are complete strangers who
have a need to communicate securely, it is usual to employ a different
scheme, making use of the services of a "Trusted Third Party"
(conventionally known as Trent). In such a scheme Alice and Bob (along
with many others) each generate their private and public keys, and each
send their public keys to Trent. Trent creates a 'certificate' for each
of them -- a digital record of their identity and their public key,
signed by Trent -- and returns it to them. Trent then makes his own
public key widely known (and arranges for it to be distributed widely by
the likes of Microsoft, Apple, Mozilla, etc., so that every computer
user in the land will have copy). Alice and Bob can then provide each
other with copies of their public key certificates, and as each trusts
Trent they both trust that the keys are genuine.
For this to work, Trent must establish his credentials as a trustworthy
intermediary. He must demonstrate that he performs some degree of
checking of the credentials presented to him by Alice and Bob (and all
the others) before issuing their certificates. He must demonstrate that
his own private key, which is used to sign the certificates, is managed
securely and is not liable to become known to Eve (or anyone else). He
will probably have to support his claim to trustworthiness by offering
financial compensation to any user of his certificates who nevertheless
suffers loss through fraud -- and for this he will probably have to pay
a hefty insurance premium. The issuing of secure and trustworthy
certificates is big business, and there is a charge for certificates
issued by commercial Certification Authorities, the actual cost
depending on the effort put into the checking of credentials and the
amount of insurance offered.
Cheers,
Daniel. |
|
| |
|
| Back to top |
Allen Kistler
Guest
|
| Posted: Sun Nov 16, 2008 1:38 am Post subject: Re: GPG |
|
|
Doug Laidlaw wrote:
| Quote: | Allen Kistler wrote:
Doug Laidlaw wrote:
I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I
will never use, and locales that I will never use, with no better
justification than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If
such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
Several points:
The only thing signing your payment card info does is assure the
recipient that you and only you sent it, assuming the recipient uses GPG
or PGP and has your public key.
Signing your payment card info does not in any way "protect" it from
interception.
To protect the info in transit, you need the recipient's public key and
you need to use it to encrypt the data to him (and maybe to yourself so
you can read what you sent).
If you use a reliable method to transport information confidentially to
someone who's careless with the info after he gets it, then you should
make sure that he's contractually liable for negligence on his part. If
you can enforce no such liability on someone who's known to be
negligent, why are you sending him confidential information? That's not
a technical problem, and it's not going to have a technical solution.
The whole thing of interception is interesting. Here is a parallel from my
working life:
[snip]
I don't fully understand GPG/PGP, but I get the point about the public key.
Hal queried it. As I understand it, I sign the message with the
recipient's public key (if he has one,) and that is like putting on it a
padlock to which only he has "the key." Only he can unlock it. I just
wonder about email sent to mailing lists which is signed with the sender's
key. Unless that protects it in transit, it is only proof of authenticity,
which isn't important on a public list, but may be good as a general
practice.
|
Other folks have responded, but I'll try to give a brief summary.
In public key crypto, keys come in pairs. One is private. You keep
that one to yourself. One is public. You spread that one far and wide.
That's why it's public.
A sender can sign a message electronically just like he can sign a paper
message. If the mechanism (PGP/GPG is one example) is reliable, then
it's "very hard" for someone else to alter the message and forge a new
signature on it. (It is, after all, *possible* to chop down the
mightiest tree in the forest with a herring.)
You sign a message with your private key. Everybody else can read the
message and verify the signature with your public key, because everybody
(who so chooses) knows it.
A sender can encrypt a message using the recipient's public key,
assuming the recipient has published one. Such a message is protected
from being read by unauthorized parties in transit, because only someone
with the matching private key can decrypt it.
Why do people sign their posts on public lists? Well, they could do it
just to be cool. ("Hey, everybody, I use crypto.") More practically,
they do it to make sure they're not misquoted. Anyone who checks the
original post would be able to verify it's authenticity. If the words
of a valid original differ from the quote, then you know the poster was
misquoted.
Because of the nature of Usenet, anyone can post messages as anyone
else. Historically that's not been much of a problem, but I have seen
flame wars where opposing parties posted messages as the other party,
even including signatures to make the fake messages look real. Of
course, anyone could have carefully checked all the signatures to see
which were real and which were fake, but that would (my opinion) make
them the second group of people with too much time on their hands
described in this paragraph. |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Sun Nov 16, 2008 2:20 am Post subject: Re: GPG |
|
|
Doug Laidlaw <doug@dougshost.invalid> writes:
| Quote: | I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
|
"asymmetric cryptography" is technology where there are a pair of keys
.... what one key encodes, the other key decodes. this is in contrast to
symmetric key technology where the same key is used to both encode &
decode.
"public key" is a business process is where one of the key pair is
designated "public" and is freely published. the other key is kept
private & confidential and never divulged.
"public key" business process can be used to address the key
distribution problem in symmetric key infrastructures. it also addresses
problem of repositories of symmetric keys which may become compromised
(it isn't necessary to keep "public keys" confidential in the way that
"symmetric keys" are required to be kept confidential).
knowing somebody's "public key" allows anybody to encode information and
transmit it knowing that only the entity with the corresponding "private
key" is able to decode it.
only the appropriate entity can decode the information, however the
recipient won't know who the sender was.
"digital signature" is a business process where an entity typically
encodes a representation of information (typically a secure hash of the
information, but it could be the whole message) with their private key.
anybody can use the entity's corresponding public key to do a decode
operation to validate the origin of the information.
SSL uses a form of public/private key technology to encrypt information
transmottied on the internet.
we had been called in to consult with a small client/server startup that
wanted to do payment transactions on their server ... and had this
technology called SSL they wanted to use. Part of that effort involved
deploying something called a payment gateway ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#gateway
and the result is now frequently called "electronic commerce". This use
of SSL for electronic commerce (to hide the financial transaction
details) is still the major use on the internet today.
In the case of SSL, there is an additional business process called
"digital certificates" and institutions frequently called "certification
authorities". As part of the "electronic commerce" activity ... we had
to do some end-to-end business process audits of these (at the time) new
entities calling themselves "certification authorities". The design
point of "digital certificates" is a way of publishing information
related to the entity associated with public/private key pair ... for
first time communication between strangers. This is analogous to the
letters of credit/introduction from the sailing ship days where the
relying party had no other recourse about the stranger they were dealing
with.
In the case of GPG/PGP, public keys may be exchanged between parties w/o
requiring 3rd party certification authorities.
In the mid-90s, after having worked on this thing now called "electronic
commerce", we were asked to participate in the x9a10 financial standard
working group which had been given the requirement to preserve the
integrity of the financial infrastructure for *ALL* retail
payments. Part of that effort involved detailed, end-to-end, threat and
vulnerability studies of the various environments (internet,
point-of-sale, debit, credit, unattended, transit, stored-value, etc,
i.e. *ALL*). The outcome of that was the x9.59 financial standard
transaction protocol ... some references
http://www.garlic.com/~lynn/x959.html#x959
X9.59 protocol slightly tweaked the paradigm to require transactions to
be authenticated ... one scenario is very light-weight digital
signature. It turns out that with authenticated transaction, it is no
longer necessary to "hide" the transaction details. This eliminates the
threats from skimming, evesdropping, and data breaches. It doesn't
eliminate skimming, evesdropping, and data breaches ... but it
eliminates the threat that crooks can use the information to perform
fraudulent financial transactions. As a side-effect, it also eliminates
the major use of SSL on the internet for hiding electronic commerce
transactions.
As an aside, there were some other financial transactions specification
efforts going on at the same time as x9a10 in the mid-90s ... which also
looked at leveraging public/private key technologies ... but in
association with "digital certificates". Part of this issue was that
with prior relationship between an individual and their financial
institutional ... it invalidated design point of "digital certificates"
for first time communication between strangers ... renduring the
"digital certificates" redundant and superfluous. The other issue
was that the redundant and superfluous "digital certificates" enormously
increased the typical payment transaction payload size and processing
overhead by factor of 100 time ... misc past posts mentioning this
enormous bloat represented by redundant and superfluous "digital
certificates"
http://www.garlic.com/~lynn/subpubkey.html#bloat
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Nico Kadel-Garcia
Guest
|
| Posted: Sun Nov 16, 2008 3:09 am Post subject: Re: GPG |
|
|
Doug Laidlaw wrote:
| Quote: | I don't fully understand GPG/PGP, but I get the point about the public key.
Hal queried it. As I understand it, I sign the message with the
recipient's public key (if he has one,) and that is like putting on it a
padlock to which only he has "the key." Only he can unlock it. I just
wonder about email sent to mailing lists which is signed with the sender's
key. Unless that protects it in transit, it is only proof of authenticity,
which isn't important on a public list, but may be good as a general
practice.
Doug.
|
That authenticity can be very important. If someone is likely to forge your
email and make libelous or fraudulent claims, then sue you or get you sued for
them, or simply embarass you, proving that it wasn't you can be very
difficult. The PGP key signature technique came into a heyday during the
alt.religion.scientology fiascos, when the cult had people spewing thousands
of messages a night into the newsgroup to cloud the group, forged messages in
other people's names, forged cancellation messages for other people's
messages, and generally made it necessary for active critics of the post to
demonstrate the authenticity of their posts for their own safety.
Check out www.xenu.net for some of the history. A lot of lessons for public
mail servers and news servers were learned or driven home then. |
|
| |
|
| Back to top |
|
