Re: public-key: the wrong model for email?

2004-09-22 Thread Ben Laurie
Ed Gerck wrote:
Ben Laurie wrote:
Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?

Let's assume for a moment that a solution exists that satisfies your 
requirements. Since the recipient _must_ be able to read the document 
in the end, and is assumed to be incapable of securing their software, 
then the document is still available to third parties without the 
consent of the sender, is it not?

The recipient was not assumed to be entirely incapable of securing his
software. The recipient can be trusted to do a number of things that are
basic, for example, to operate an email software. In fact, we can even
assume a pretty sophisticated recipient, trained to use all the security
email software systems commercially available. Still, the recipient will
be incapable of verifying whether his RSA private-key is weak or not. Thus,
even fully unwillingly and under best efforts, the recipient can put the
sender's message security at risk when using that recipient's RSA public-
key.
Since they are using good software, the key is known to be strong, surely?
It seems to me that fixing the PK problem would in no way improve 
the senders situation given that threat model.
The sender's situation can be improved mostly when the sender trusts the
least possible (ideally, nothing) regarding message security. In other
words, the sender would like to avoid anything that is not under control or
cannot be directly verified by the sender. Doing a background check of the
recipient is orthogonal to the PK problem. It does not help nor solve it.
I didn't suggest a background check would help. I am suggesting that if 
you cannot rely on the recipient (or their machine) to manage keys 
properly, then you also cannot rely on them to manage decrypted emails 
properly.

Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-18 Thread Ed Gerck
Ben Laurie wrote:
Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?
Let's assume for a moment that a solution exists that satisfies your 
requirements. Since the recipient _must_ be able to read the document in 
the end, and is assumed to be incapable of securing their software, then 
the document is still available to third parties without the consent of 
the sender, is it not?
The recipient was not assumed to be entirely incapable of securing his
software. The recipient can be trusted to do a number of things that are
basic, for example, to operate an email software. In fact, we can even
assume a pretty sophisticated recipient, trained to use all the security
email software systems commercially available. Still, the recipient will
be incapable of verifying whether his RSA private-key is weak or not. Thus,
even fully unwillingly and under best efforts, the recipient can put the
sender's message security at risk when using that recipient's RSA public-
key.
It seems to me that fixing the PK problem would in no way improve the 
senders situation given that threat model.
The sender's situation can be improved mostly when the sender trusts the
least possible (ideally, nothing) regarding message security. In other
words, the sender would like to avoid anything that is not under control or
cannot be directly verified by the sender. Doing a background check of the
recipient is orthogonal to the PK problem. It does not help nor solve it.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-18 Thread Ed Gerck
Anne  Lynn Wheeler wrote:
At 12:53 PM 9/16/2004, Ed Gerck wrote:
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?

a complete audit and background check ... would include an audit of 
the recipient ... not just the recipient person  but the recipient 
... as in the recipient operation.
I agree with you that more checks is usually better. But if you are talking
about someone else verifying the recipient's machine, we're talking about
what seems to me to be a much worse security risk. Who exactly would you
trust to verify your machine and potentially read your decrypted email and
other documents? A neutral third-party? Just allowing a third-party to
have access to my machine would go against a number of NDAs and security
policies that I routinely sign. Further, in terms of internal personnel doing
it, we know that 70% of the attacks are internal. The solution to my email
security problem should not be installing a back-door in your machine.
(snip) the 
leakage of a classified document wouldn't solely be restricted to 
technical subversion.
The leakage of a classified document has a number of aspects to consider
in order to prevent it, as we all know. From the sender's viewpoint, however,
what strategy should have the most impact in reducing leakage of a classified
document? It seems clear to me that it is in avoiding anything that is not
under control or cannot be directly verified by the sender. In other words,
it should be more effective to eliminate the sender's reliance on the
recipient's public-key (the sender cannot control or verify whether the key
is weak or not) than do yet another background check of the recipient operation.
Even if the recipient passes today, it may be vulnerable tomorrow. The
sender can't control it.
Cheers--/Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Adam Shostack
On Thu, Sep 16, 2004 at 06:12:48PM +0100, Ian Grigg wrote:
| Adam Shostack wrote:
| Given our failure to deploy PKC in any meaningful way*, I think that
| systems like Voltage, and the new PGP Universal are great.
| 
| I think the consensus from debate back last year on
| this group when Voltage first surfaced was that it
| didn't do anything that couldn't be done with PGP,
| and added more risks to boot.  So, yet another biz
| idea with some hand wavey crypto, which is great if
| it works, but it's not necessarily security.

Sure, I like the system even if it breaks, because it focuses on ease
of use.  I didn't say I thought it secure.

| * I don't see Verisign's web server tax as meaningful; they accept no
| liability, and numerous companies foist you off to unrelted domains.
| We could get roughly the same security level from fully opportunistic
| or memory-oportunistic models.
| 
| Yes, or worse;  it turns out that Verisign may very
| well be the threat as well as the solution.  As I
| wrote here:
| 
| http://www.financialcryptography.com/mt/archives/000206.html
| 
| Verisign are in the eavesdropping business, which
| not only calls into doubt their own certs, but also
| all other CAs, and the notion of a trusted third
| party as a workable concept.

Yes.

Adam

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Bill Stewart
At 10:19 PM 9/15/2004, Ed Gerck wrote:
Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some key-access feature. Nonetheless, the sender has to use that key.
I don't understand the threat model here.  The usual models are
- Key too short - Obvious to the sender
- Recipient's machine is compromised
- Not obvious to sender, but not fixable by email program
- Recipient is stupid and careless
- Often obvious to sender, but not fixable by email program
- Recipient's Public Key generator system generates weak keys
- Hard for sender to detect and work around
- Usually requires extra work by recipient to obtain
compromised software, unless mandated by Corporate IT Droids
- Recipient can reduce risk by using open source software
- Recipient's Public Key generator mails copy of private key to 
keyserver.kgbvax.gov
- Indistinguishable from previous case
- Recipient's Client Software mails copy of session key to ashcroft.kgbvax.gop
- Indistinguishable from previous case
- Recipient's Email Client forwards incoming mail message plaintext
disguised as bouncegrams or viruses.
- Indistinguishable from previous case.
- Recipient's Secret Key is recipient's dog's name spelled backwards,
written on yellow sticky note pasted next to open window,
under the big mirror with a good view of recipient's keyboard and 
screen.
- Not a software problem
- Recipient's Computer Disk automatically backed up to optical storage at night
- No sense subpoenaing cyphertext when you can subpoena plaintext.

You're focusing on a relatively niche threat model,
unless there's some operational aspect here I'm missing.
If you wanted to do something fancy, you could insist that the
recipient send the sender a Diffie-Hellmann Half-Key,
which you use to generate a session key that you use for message encryption,
and transmit your DH half-key along with the encrypted message
for the sender to decrypt.  It's still subject to most of the same threats
as the RSA-like public-key model, though maybe it's a bit easier
to detect weak Diffie-Hellmann keys.  However, unless you want to
force the recipient to change their client interface,
the easier place to implement something is in their SMTP client,
and the obvious way to do that is some variant on SSL-SMTP.
If you _still_ want more control, set up a web server,
and instead of sending your actual secret message, send
Encrypt ( Key=Alice, Message=
- BEGIN PGP SIGNED MESSAGE
Alice - I've sent you an encrypted message at
https://bob.example.net/cookie123456.PGP
This URL will self-destruct in 5 business days.
- Bob
- END PGP SIGNED MESSAGE
)
However, if Alice was using a compromised email client,
she could just as easily be using a compromised browser. 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Ed Gerck
Adam Shostack wrote:
On Thu, Sep 16, 2004 at 12:05:57PM -0700, Ed Gerck wrote:
| Adam Shostack wrote:
| 
| I think the consensus from debate back last year on
| this group when Voltage first surfaced was that it
| didn't do anything that couldn't be done with PGP,
| and added more risks to boot.
| 
| Voltage actually does. It allows secure communication
| without pre-registering the recipient.

Generate a key for [EMAIL PROTECTED] encrypt mail to
Bob to that key.  When Bob shows up, decrypt and send over ssl.
How do you know when the right Bob shows up? And...why encrypt? The
email never left your station. Your method is equivalent to: send
anything to Bob at [EMAIL PROTECTED]. When Bob shows
up pray he is the right one and send email over ssl. You also have to
run an ssl server (or trust Bob's server key).
With Voltage, you encrypt the email to [EMAIL PROTECTED]
and send it. The sender's work is done[*]. Yes, the other problems still
exist with Voltage.
Cheers,
Ed Gerck
[*] The recipient can decrypt the Voltage email only IF both the sender
and  recipient can refer to the same key generation parameters for the
recipient. This is a problem that I have not seen Voltage discuss. Users
in different or competing administration boundaries will not be able
to communicate with each other in general.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Anne Lynn Wheeler
At 05:35 PM 9/16/2004, Adam Shostack wrote:
Generate a key for [EMAIL PROTECTED] encrypt mail to
Bob to that key.  When Bob shows up, decrypt and send over ssl.

note there is still the issue of knowing it is bob ... whether before the 
transmission or after the transmission  and, in fact, the 
transmission itself is somewhat arbitrary.

in the physical world ... the base point is that the sender pays to 
physically transmit something. there is threat model of taking physical 
possession of whatever is being transmitted. they then pay extra for 
countermeasures wrong person taking physical possession. they also pay 
extra for extra care in delivery to the correct person.

the current electronic world ... the base point is that the sender doesn't 
actually pay per transmission. with encryption, the threat model is changed 
to possession of the unencrypted information. encryption (shared-secret or 
digital signatures) is also used to help with the issue of delivery to 
the correct person (although the convention is converted to the correct 
person decrypts the data).

so what is the difference between the sender setting up facility so that 
when bob shows up  bob gets a decrypted version  and say sending 
a version to some trusted 3rd party that is encrypted with the 3rd party's 
key ... and direction to only let bob have it when bob shows up. how does 
the 3rd party know its bob ... any better than the originating sender? note 
also in standard ssl ... the recipient generates a random symmetric key and 
sends it to the server, encrypted with the server's public key. there is 
nothing about how the server knows that the bob making the contact ... and 
the bob that is suppose to receive the information  is the same entity.

so the 3rd party keeps the pre-transmitted encrypted stuff with directions 
to only give it to any entity that shows the magic something (the movie 
stuff about tearing a bill in half and the person needs to have the 
appropriate torn half).  the 3rd party holds it until bob contacts the 
sender and gets the magic something ... which they they can give to the 3rd 
party. given the nature of electronic transmission ... is that really 
substantially different than the sender waiting until bob contacts them 
before doing the original transmission.

if it is purely electronic world ... how does the sender get the necessary 
information to the correct bob ... so that the correct bob can give the 
stuff to the 3rd party ... to proove that they are the correct bob.

so possibly the only distinction ... is that the email communication 
between bob and the sender is non-real-time ... and the SSL communication 
is considered possibly real-time  so the scenario isn't actually the 
information being transmitted between the sender and bob that is the issue 
... it is possibly the mechanics of real-time vis-a-vis non-realtime?

so the sender at some point has to trust bob's authentication information 
(whether directly and/or outsourced to 3rd party) ... say digital signature 
public key and may or may not trust that same key for encryption.

common pgp flow ... which effectively is the same as ssl   same process 
steps ... but possibly not in real time. sender looks up in some directory 
the contact information for bob,
this directory is trusted to map the contact process for bob to bob  
the directory may or may not also provide some authentication information 
for bob.  if the sender doesn't have authentication information for bob ... 
they send message to bob requesting authentication information. when they 
get that back, they vet the authentication information before using it to 
make sure it is actually for bob. so now they have a process which has some 
assurance of contacting bob and some assurance that bob can be authenticated.
this is pretty much true whether the actual sender is responsible for the 
steps or has been outsourced to some 3rd party.

now the issue is wether or not the authentication information is also 
trusted to securely protect the classified information during transmission 
(aka public key).  possible scenario if sender  requires different 
encryption keys from authentication information:

1) sender sends message to bob saying classifed document is waiting. bob 
generates secret key, digitally signs it, encrypts it with the senders 
public key and returns it to the sender. this could be all email exchange 
... or possibly combination of email and ssl  it could also be directly 
with the sender or a 3rd party agent on the sender's behalf.

2) the sender decrypts bob's message, validates the digital signature, 
encrypts the classified information with bob's secret key and sends the 
information to bob. the sender's process can be email or ssl ... and can 
either directly be the sender ... or a 3rd party acting on the sender's behalf.

for efficiency purposes  the acquisition of bob's authentication 
information and possible encryption key 

Re: public-key: the wrong model for email?

2004-09-17 Thread lrk
On Thu, Sep 16, 2004 at 04:57:39PM -0700, Bill Stewart wrote:
 At 10:19 PM 9/15/2004, Ed Gerck wrote:
 Yes, PKC provides a workable solution for key distribution... when you
 look at servers. For email, the PKC solution is not workable (hasn't been)
 and gives a false impression of security. For example, the sender has no
 way of knowing if the recipient's key is weak (in spite of its length)
 or has some key-access feature. Nonetheless, the sender has to use that 
 key.
 
 I don't understand the threat model here.

That seems to be the actual problem. If you want real security, you need a
vault, guards, cryptographers, and do the crypto in the vault.

I use GnuPG so my e-mail is in an envelope rather than on a postcard.
If the fedz want to read it they bring guns, slammers, and rubber hoses
anyway.


Perhaps it is time to define an e-mail definition of crypto to keep the
postman from reading the postcards. That should be easy enough to
implement for the average user and provide some degree of privacy for
their mail. Call it envelopes rather than crypto. Real security 
requires more than a Windoz program.


-- 
[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Ian Grigg
lrk wrote:
Perhaps it is time to define an e-mail definition of crypto to keep the
postman from reading the postcards. That should be easy enough to
implement for the average user and provide some degree of privacy for
their mail. Call it envelopes rather than crypto. Real security 
requires more than a Windoz program.
Oh, that's really easy.  Each mailer (MUA) should (on
install) generate a self-signed cert.  Stick the fingerprint
in the headers of every mail going out.  An MUA that sees
the fingerpring in an incoming mail can send a request email
to acquire the full key.  Or stick the entire cert in there,
it's not as if anyone would care.
Then each MUA can start encrypting to that key opportunistically.
Lots of variations.  But the key thing is that the MUA
should simply generate the key, sign it, and send it out
on demand, or more freuqently.  There's really no reason
why this can't all be automated.  After all, the existing
email system is automated, and trusted well enough to
deliver email, so why can't it deliver self-signed certs?
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-17 Thread Ed Gerck
Bill Stewart wrote:
At 10:19 PM 9/15/2004, Ed Gerck wrote:
Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't 
been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some key-access feature. Nonetheless, the sender has to use 
that key.

I don't understand the threat model here.  The usual models are
 ...
Good list, even though missing some points that are important here,
mentioned below.
The disclosure threat is that the message may be disclosed AFTER it is
decrypted (this may happen even without the recipient being at fault).
I am NOT talking about the disclosure threat. Except for the disclosure
threat, the threat model includes anything that is not under control
or cannot be directly verified by the sender.
The obvious strategy for the sender is to trust the least possible
(ideally, nothing) regarding message security.
Public-key encryption for email makes this difficult from the start.
With all the public-key fancy foot work (eg, CA certs, CRL, OCSP, etc.),
the sender still has to trust the public-key generated by the recipient
regarding its basic property to encrypt messages that can only be
decrypted by the recipient when the message arrives.
Yes, the sender can do a challenge-response using that key and confirm
that the recipient has the private-key. But what the sender does not
have, and cannot have, is any assurance that his messages are only
decryptable by the recipient. The sender has no way of knowing if the
recipient's public-key is weak (in spite of its great length), or has
some key-access feature, or bug, or has been revoked in the mean
time [1]. Trusting the recipient helps but the recipient may not even
know it (in spite of the recipient's best efforts).
This problem also affects SSH and anything that uses public-key crypto,
including smart-card generated keys. For email, however, it can break
message security in spite of the sender's and recipient's best efforts.
Since the sender is the party who bears most, if not all, the risk, my
question was whether email security could benefit by using a different
model. Public-key crypto could still be used, but possibly not as it
is today. Again, the problem is both technical and business-wise.
If you _still_ want more control, set up a web server,
and instead of sending your actual secret message, send
Encrypt ( Key=Alice, Message=
- BEGIN PGP SIGNED MESSAGE
Alice - I've sent you an encrypted message at
https://bob.example.net/cookie123456.PGP
This URL will self-destruct in 5 business days.
- Bob
- END PGP SIGNED MESSAGE
)
The attacker could read the first message and download the second message.
It could make it detectable, though (but not necessarily traceable).
Cheers,
Ed Gerck
[1] The security fault happens when you (in spite of all your best efforts) send
an email message using a public-key that is revoked (eg, because the private-key was
compromised) at the time the message is received, due to various delays such as in
message transport, certificate revocation, and compromise discovery. You simply have
no way of knowing, even if the key was not listed in a CRL at the very second you
sent the message, whether the key has not been compromised at the time the message
is received. It gets worse. If the private-key is compromised any time after the
message is sent, the message can be decrypted from a cache copy somewhere -- even
if the recipient keeps the decrypted copy safe.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: public-key: the wrong model for email?

2004-09-16 Thread Weger, B.M.M. de
Hi Ed,

What about ID-based crypto: the public key can be any string, such as
your e-mail address. So the sender can encrypt even before the
recipient has a key pair. The private key is derived from the
public key by a trusted party when the recipient asks for it.
Yes, the recipient does have some burden here, but it seems to
me that that is unavoidable.
I'm not saying that this is without problems (private key distribution,
inherent key escrow / recovery, revocation issues), or that it's easier 
manageable than traditional PKI, but it may solve some of your issues.

The idea for ID-based crypto comes from Adi Shamir, back in 1984.
The first practical and mathematically sound realisation is due to
Boneh and Franklin (Crypto 2001), and is brought to the market
by Voltage (www.voltage.com). I don't know their products, only that
it exists, and I'm not a shareholder. I do think it's interesting
math and interesting crypto, and that it could lead to interesting 
technology.

Grtz,
Benne de Weger

= 
Technische Universiteit Eindhoven 
Coding  Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
tel. (040) 247 2704, bgg 5141 
e-mail: [EMAIL PROTECTED] 
www: http://www.win.tue.nl/~bdeweger 
= 
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck
 Sent: woensdag 15 september 2004 20:39
 To: [EMAIL PROTECTED]
 Subject: public-key: the wrong model for email?
 
 [Perry: please use this version, if possible]
 
 Public-key cryptography burdens the recipient and puts the 
 recipient in charge, while the sender is at the recipient's 
 mercy. Is this the right model for email security? After all, 
 the sender is the party at risk.
 
 To clarify, my comment is not that PKC is not useful for 
 email. I believe it is, but not directly used as it is today.
 
 What I am saying is that the problem is key distribution. I 
 want to separate the key distribution solution as directly 
 done by PKC today (send the public-key) from a possible 
 general solution for PKC key distribution that does not 
 require sending the public-key. The point is that when PKC 
 solves this problem directly, it solves it in a way that's 
 useful for webservers (the webserver does not have to trust 
 the client's certificate) but presents difficulties for email 
 senders (the sender has to trust the recipient's 
 certificate). Email use of PKC treats the recipient as a server.
 
 I think that what we need is a key distribution method for 
 email (that can still use PKC and PKI) where, because the 
 sender has all the risk, the sender defines how email is 
 secured and delivered. The recipient should always be able to 
 receive it, without too much burden or required previous work.
 
 For example, let's see how FedEx works. The sender chooses 
 the service and the type of envelope to protect the message. 
 The sender also chooses the instructions that must be 
 followed before the envelope can be opened by the recipient.
 The recipient has no charge to pay for, or burden, in order 
 to receive the envelope, and does not have to do anything 
 before the envelope is sent. The recipient is able to verify 
 the identity of the sender and, if so desired, refuse the 
 envelope. The recipient can open the envelope if and only if 
 the recipient is willing to follow the sender's instructions 
 (e.g., providing name, address, date, signature).
 
 Yes, SSL and public-key encryption are and continue to be a 
 success for web servers. However, the security model for 
 protecting email with public-key cryptography seems to be 
 backwards, technically and business wise. The sender, who is 
 the party at risk, has to trust a lock provided by the recipient (his
 public-key) to protect her secrets (the message). If FedEx 
 would provide message security a la PGP, PGP/MIME or S/MIME 
 email, the sender would have to convince the recipient to pay 
 and send in advance an envelope for the sender to use.
 The sender, however, would never know whether the envelope 
 indeed prevented others from prying into its contents.
 
 A better situation would arise if the lock (i.e., the 
 envelope) would be controlled by the sender. Moreover, the 
 recipient is not the business driver who needs to provide, 
 pay for and protect the lock. The sender is the party who has 
 the motivation to spend money to provide and protect the lock.
 
 In short, I find that public-key cryptography cannot solve 
 the security issues of email when used as it is today and, 
 most importantly, cannot provide the needed motivation for 
 users, senders and recipients, to buy into it.
 
 It's not a matter of improvements in usability, better 
 pricing or user education [1]. It simply does not work as it 
 should work. That's also why, IMO, it does not take off. It 
 is using the wrong mathematics for the problem.
 
 Does

Re: public-key: the wrong model for email?

2004-09-16 Thread Ed Gerck
Anne  Lynn Wheeler wrote:
PGP allows that a relying party vet a public key with the key owner 
and/or vet the key with one or more others (web-of-trust)

note that while public key alleviates the requirement that a key be 
distributed with secrecy ... it doesn't eliminate the requirement that 
the public key have some trust characteristic associated (i.e. secrecy 
will tend to include some trust, but elimination of secrecy doesn't 
eliminate the requirement for trust).
Lynn,
My question on this is not about trust, even though I usually have  many
questions on trust ;-)
Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some key-access feature. Nonetheless, the sender has to use that
key.
The analogy here is with you sending a confidential document using a courier
you don't know and cannot verify. Would you?
Further, it is generally in the recipient's interest that the decision to
send document X using channel Y should be under the sender's control. Any
limitation or directive imposed by the recipient on the sender (such as:
use my public-key) can shift the burden of risk to the recipient (your key
was weak, hence I had a loss). Liability follows power. The current use of
PKC in email is neither good to the sender nor to the recipient.
To further clarify, my comment is not that PKC is not useful for email. I
believe it is, but not directly used as it is today. The PKC key distribution
solution is backwards for email.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-16 Thread Adam Shostack
Given our failure to deploy PKC in any meaningful way*, I think that
systems like Voltage, and the new PGP Universal are great.

* I don't see Verisign's web server tax as meaningful; they accept no
liability, and numerous companies foist you off to unrelted domains.
We could get roughly the same security level from fully opportunistic
or memory-oportunistic models.

Adam

On Thu, Sep 16, 2004 at 02:05:15AM -0700, Ed Gerck wrote:
| Benne,
| 
| With Voltage, all communications corresponding to the same public key can be
| decrypted using the same private key, even if the user is offline. To me, 
| this
| sounds worse than the PKC problem of trusting the recipient's key. Voltage
| also corresponds to mandatory key escrow, as you noted, with all its 
| drawbacks.
| 
| Cheers,
| Ed Gerck
| 
| Weger, B.M.M. de wrote:
| 
| Hi Ed,
| 
| What about ID-based crypto: the public key can be any string, such as
| your e-mail address. So the sender can encrypt even before the
| recipient has a key pair. The private key is derived from the ...
| 
| -
| The Cryptography Mailing List
| Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-16 Thread Anne Lynn Wheeler
At 11:19 PM 9/15/2004, Ed Gerck wrote:
Yes, PKC provides a workable solution for key distribution... when you
look at servers. For email, the PKC solution is not workable (hasn't been)
and gives a false impression of security. For example, the sender has no
way of knowing if the recipient's key is weak (in spite of its length)
or has some key-access feature. Nonetheless, the sender has to use that
key.

the issue then is what level do you trust the recipient, what is the threat 
model, and what are the countermeasures.

if there is a general trust issue with the recipient (not just their key 
generating capability) ... then a classified document compromise could 
happen after it has been transmitted. you may have to do a complete audit  
background check of the recipient before any distribution of classified 
document.

if the threat model is purely the document transmission, and you worry only 
about the recipient's key generating capability being up to the task of 
protecting the document transmission ... but you otherwise aren't worried 
about other trust issues with the recipient ... then go for 3rd party 
secure transmission service ... say where the encrypted package is 
delivered to the recipient and the recipient has to do some sort of 
real-time retrieval from the 3rd party of the package encryption key.

in the physical world ... there still could be the issue that the delivery 
address for the recipient (to be used by the 3rd party delivery service) 
might not be trusted.

part of the problem with introducing trust issues involving any specific 
recipient issue starts a real slippery slope   since the security of 
the system is all of the infrastructure  and just addressing a single 
recipient trust issue (like key generation strength)  still leaves open 
all sorts of other recipient trust issues.

say you have 3rd party encryption and secure delivery ...  with the 
possibility that the electronic package might be evesdropped (copied but 
not decoded). the issue then is how does the 3rd party know that the 
correct recipient is the only one that obtains the correct decryption key. 
there has to be some trust at some point that the correct recipient and 
only the correct recipient can decode any encrypted electronic package. at 
some point there has to be some flavor of trusting some sort of recipient 
authentication mechanism.

either the sender has it before hand (like the recipient's public key) or 
there is some sort of post-transmission authentication of the recipient. 
eliminating the requirement for strong authentication of the recipient 
before the transmission doesn't really eliminate the problem, it just moves 
it to some point.

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/ 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-16 Thread Ian Grigg
Adam Shostack wrote:
Given our failure to deploy PKC in any meaningful way*, I think that
systems like Voltage, and the new PGP Universal are great.
I think the consensus from debate back last year on
this group when Voltage first surfaced was that it
didn't do anything that couldn't be done with PGP,
and added more risks to boot.  So, yet another biz
idea with some hand wavey crypto, which is great if
it works, but it's not necessarily security.
* I don't see Verisign's web server tax as meaningful; they accept no
liability, and numerous companies foist you off to unrelted domains.
We could get roughly the same security level from fully opportunistic
or memory-oportunistic models.
Yes, or worse;  it turns out that Verisign may very
well be the threat as well as the solution.  As I
wrote here:
http://www.financialcryptography.com/mt/archives/000206.html
Verisign are in the eavesdropping business, which
not only calls into doubt their own certs, but also
all other CAs, and the notion of a trusted third
party as a workable concept.
iang
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-16 Thread Ed Gerck
Anne  Lynn Wheeler wrote:
  the issue then is what level do you trust the recipient, what is the
threat model, and what are the countermeasures.
if there is a general trust issue with the recipient (not just their key 
generating capability) ... then a classified document compromise could 
happen after it has been transmitted. you may have to do a complete 
audit  background check of the recipient before any distribution of 
classified document.
If the recipient cannot in good faith detect a key-access ware, or a
GAK-ware, or a Trojan, or a bug, why would a complete background
check of the recipient help?
Talking about trust, it is important to note that when the email is sent
the recipient is already trusted not to disclose. But even though the
recipient is trustworthy his environment may not be. It is not a matter of
personal trust  or complete background checks. This may all be fine
and, unknown to the recipient, the key might be weak, on purpose or by
some key-access feature included in the software (unknown to the user).
Or, the PKC software may have a bug (as PGP recently disclosed).
Loss from disclosure is also something that is much more important for
the sender. If the recipient's public-key fails to be effective in
protecting the sender, the sender's information is compromised. That's
why I make the point that PKC for email has it backwards: the sender
should not be at the recipient's mercy.
PKC for email also reverses the usual business model, because the
recipient is not so interested in protecting the sender or paying
for the sender's security. The sender would.
Regarding the use of PKC to sign emails, I see no problems using
PKC. The sender has the private-key, has the incentive to keep it
secure, and uses it to sign when he so desires. The sender does not
need to rely on the recipient, or receive anything from the recipient,
in order to sign an email. The problem with PKC email signature is
PKI. However, email signature can also be done without PKI, by PGP.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-16 Thread Ed Gerck
Adam Shostack wrote:
I think the consensus from debate back last year on
this group when Voltage first surfaced was that it
didn't do anything that couldn't be done with PGP,
and added more risks to boot.
Voltage actually does. It allows secure communication
without pre-registering the recipient.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: public-key: the wrong model for email?

2004-09-15 Thread Anne Lynn Wheeler
At 12:39 PM 9/15/2004, Ed Gerck wrote:
 [1] Public-key cryptography gives the impression that email message 
security can
 be achieved quite simply. The public-key can be distributed at will, no 
need for
 secrecy, and anyone can receive private and secure messages. The same 
procedure
 being applied to each side, sender and receiver, both could immediately 
engage
 in private and secure communication.

there are (at least) 2-3 characteristics of various public key systems
1) the public key doesn't have to be kept confidential as part of the 
distribution

2) you don't need a unique key for every unique security /or business domain
3) other parties can attest to any bindings between the public key and 
other characteristics

however, while the fact that public key secrecy isn't required (vis-a-vis 
secret keys) ... and possibly enables one or more of the mentioned 
characteristics, public key operation doesn't mandate all such 
characteristics be mandatory for the use of public keys.

PGP allows that a relying party vet a public key with the key owner and/or 
vet the key with one or more others (web-of-trust)

note that while public key alleviates the requirement that a key be 
distributed with secrecy ... it doesn't eliminate the requirement that the 
public key have some trust characteristic associated (i.e. secrecy will 
tend to include some trust, but elimination of secrecy doesn't eliminate 
the requirement for trust).

so an infrastructure analogy to physical mail for public key  is that 
public key becomes the trusted address for the recipient. in the physical 
world ... to send some mail ... you need a trusted mailing address for the 
recipient ... you need to have acquired that address in some manner and 
furthermore have some trust that it is the correct address. so lets assume 
that some number of equivalent mechanisms exist for public keys. it so 
happens that the encryption of the contents with the public key and the 
addressing of the contents with that same public key  has some 
associated trusted infrastructure that delivers the package to the correct 
recipient.

lets say that instead of having personal zip-codes and personal cell-phone 
numbers (that you take with you regardless of the service and/or physical 
location)... that can reach you regardless of where you happen to be in the 
world   the number that can be guaranteed to reach you, also happens 
to have the characteristics of a public key.

so public key mapping to entity infrastructures take on similar 
characteristics as personal (physical) mailing addresses and/or personal 
cell-phone numbers ... and then you have trusted infrastructures (usps, 
telephone companies, gov. posts) that can be relied on to make the 
connection to the appropriate recipient  which then approximates a
public key paradigm mapping to existing physical world paradigms.

in the current physical world infrastructure, the publication /or 
distribution of addresses are relatively low-cost (/or free) operations 
with the infrastructures making their real money off the delivery ... as 
opposed to the publication.

translated to the internet paradigm  everybody has a public key (in 
much the same way that everybody can have a personal cellphone number that 
may reach them regardless of where they are in the world). the public key 
is registered in something like the domain name infrastructure which then 
is able to figure out how to find you in the world (in manner similar to 
how personal cellphone number can find you anywhere in the world).

it isn't necessary that public key paradigms have to be the wrong model for 
email  it is that the various existing economic models for making money 
off of public key infrastructures may be inconsistent with normal expected 
business operations. however, there is nothing intrinsic to public keys 
that mandate they are tied to existing public key infrastructure economic 
models.

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/  

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]