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: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
On Wed, 15 Sep 2004 16:30:54 +0100, Ian Grigg said: There is a device that is similar to those characteristics: http://woudt.nl/epass-pgp/ http://www.financialcryptography.com/mt/archives/000201.html The advantage of the OpenPGP card is that is is a specification that it is open and ready for everyone to implement. No proprietary strings attached as usual in the smartcard business. So go write an application according to the specs and it will, run with any card compliant with the spec. Any vendor may implement this spec on his card. Whether you do this on a slow 4 Euro chip or a fast 8 Euro chip or on an iButton is up to you. Our card is just one implementation of the spec using an expensive chip. Werner - 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]
