Re: public-key: the wrong model for email?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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]
